Introduction into Web Services (WS)

1. Introduction into Web Services (WS) Adomas Svirskas

2. Agenda • Background and the need for WS • SOAP – the first Internet-ready RPC • Basic Web Services • Advanced Web Services • Case Studies • The ebXML framework • How do I use/develop Web Services?

3. Background and the need for WS • There is almost always a need for processes (objects, modules, components) to communicate • Inter-process communication alternatives: • Shared memory • Shared databases • Transport-level network protocols (Pipes, Sockets) • Remote procedure calls (RPC) • Distributed objects and components • Asynchronous message passing

4. Remote Procedure Call From http://users.uma.maine.edu/faculty/rsm/slides/slides.htm

5. Distributed Objects DCOM (COM+) – Microsoft Standard Windows-dependent CORBA – Object Management Group (OMG) Standard OMG – vendor-neutral consortium http://www.omg.org OS and programming language neutral From http://www.byte.com

6. J2EE Distributed Components General J2EE Architecture Component communications From http://www.tusc.com.au/tutorial/html/chap2.html

7. Why do we need more? • Interoperability issues • DCOM can‘t natively talk to CORBA • CORBA can‘t natively talk to J2EE • Expensive bridging solutions required • CORBA applications from different vendors can‘t talk between themselves • J2EE components are not portable between different servers

8. Why do we need more? • The Internet changed it all • Number of systems involved in interactions is vast compared to that within the corporate boundaries • Discovery issues • Scalability issues • Security issues • Interoperability no longer depends on decisions of the CTO of a company

9. Why do we need more? • All mentioned technologies failed to ensure integration and interoperability in the Internet environment • They were designed for the Intranets • The Internet dictated its own rules, mostly bottom-up standards and protocols, based on their widespread success

10. What is needed? • An RPC-like solution which would • Be OS and vendor agnostic • Use the standard Internet protocols (HTTP, SMTP), i.e. firewall-friendly communication • Have simple API from different programming languages • Use simple data representation

11. Web Services pioneer - XML-RPC (1998) http://www.xmlrpc.com/ From: http://www-106.ibm.com/developerworks/library/ws-xpc1/

12. XML-RPC Protocol • Uses XML and HTTP • Very simple to use • Allows disparate systems • to communicate

13. Merits of XML and HTTP • XML • Extensible Markup Language • Platform agnostic • Existing parsers for many languages • HTTP • Ubiquitous • Widely supported and firewall-friendly

14. Simple Object Access Protocol • SOAP uses the same principles as XML-RPC and builds on its success • SOAP tries to pick up where XML-RPC left off by implementing user defined data types, the ability to specify the recipient, message specific processing control, and other features. • SOAP was supported by IBM and Microsoft from its inception in 1999 • Currently SOAP 1.2 is under W3C control: http://www.w3.org/TR/soap/

15. Simple Object Access Protocol • The SOAP specification consists of roughly these areas: • A content-neutral packaging scheme • Extensibility for additional functionality • Rules for encoding common application data structures, • Types in an XML format • Bindings to HTTP transport. • SOAP's primary strength comes from its simple and extensible packaging scheme

16. SOAP Envelope From http://www.techmetrix.com/trendmarkers/publi.php?C=EW2I From http://developer.apple.com/documentation/WebObjects/Web_Services/Introduction/chapter_2_section_5.html

17. SOAP-based Communication From http://www.techmetrix.com/trendmarkers/publi.php?C=EW2I

18. Simple Object Access Protocol • SOAP is way more powerful and complex than XML-RPC • Implementations by: • IBM/Apache • Sun Microsystems • Microsoft • And others... • More useful links: • http://www-106.ibm.com/developerworks/webservices/library/ws-ref1.html • http://weblog.masukomi.org/writings/xml-rpc_vs_soap.htm • http://ws.apache.org/soap/ • http://www.xml.com/pub/a/2000/07/12/soap/mssoaptutorial.html

19. SOAP in Action – Logical View

20. SOAP in Action – Deployment View

21. SOAP in Action – Java/MS A. Svirskas December 2000

22. So what else do we need? • Wbe can do RPC over the Internet! Great! • But... we need standard ways for: • Describing SOAP service capabilities • Publishing the services • Discovering the services • Interacting with the services • Otherwise we would search for a needle in a haystack

23. Service Oriented Architecture From http://www.jot.fm/issues/issue_2002_07/column5

24. Web Services Description Language • WSDL stands for Web Services Description Language • WSDL is written in XML • WSDL is an XML document • WSDL is used to describe Web services • WSDL is also used to locate Web services • WSDL Spec: http://www.w3.org/TR/wsdl

25. WSDL Example Real world example: http://soap.amazon.com/schemas3/AmazonWebServices.wsdl

26. WSDL Structure • WSDL Ports • The <portType> element is the most important WSDL element. • It defines a web service, the operations that can be performed, and the messages that are involved. • The <portType> element can be compared to a function library (or a module, or a class) in a traditional programming language. • WSDL Messages • The <message> element defines the data elements of an operation. • Each messages can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language. • WSDL Types • The <types> element defines the data type that are used by the web service. • For maximum platform neutrality, WSDL uses XML Schema syntax to define data types. • WSDL Bindings • The <binding> element defines the message format and protocol details for each port.

27. Universal Description, Discovery and Integration • UDDI stands for Universal Description, Discovery and Integration • UDDI is a directory for storing information about web services • UDDI is a directory of web service interfaces described by WSDL • UDDI communicates via SOAP • UDDI Spec: http://www.oasis-open.org/committees/uddi-spec/

28. Web Services in Operation

29. Types of Web Services From: http://www.computerworld.com/developmenttopics/development/story/0,10801,79698,00.html

30. Asynchronous Web Services • In some situations, responses to Web service requests are not provided immediately, but rather sometime after the initial request transactions complete • Different types of underlying middleware might be used to accomplish this task: HTTP, SMTP, JMS From: http://www-106.ibm.com/developerworks/library/ws-asynch2/index.html

31. Asynchronous Web Services From: http://www.computerworld.com/developmenttopics/development/story/0,10801,79698,00.html

32. Web Services Examples • Google.com - http://www.google.com/apis/ • Amazon.com - http://associates.amazon.com/exec/panama/associates/join/developer/faq.html • eBay.com -http://www.internetnews.com/dev-news/article.php/3312341 • Many more -http://www.salcentral.com/salnet/webservicewhat.asp

33. How do I write my own WS? • Download a toolkit: • IBM - http://www.alphaworks.ibm.com/tech/ettk • Sun - http://java.sun.com/webservices/downloads/webservicespack.html • Many more implementations • Read a tutorial • http://www.theserverside.com/articles/article.tss?l=Systinet-web-services-part-1 • http://www.systinet.com/download/TutorialOne.pdf • Implement a service and test it • Enjoy the new experience

34. Do we need more? • So we can develop, publish, discover, invoke Web Services • But... this is an application integration • While the business world needs business process integration • Thus we need composable, orchestrated, transactable, secure Web Services

35. Advanced Web Services Architecture From http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/

36. Advanced Web Services Architecture Vendors such as IBM, BEA, Microsoft teamed up together with OASIS and W3C to provide business-grade Web Services framework From http://www-306.ibm.com/software/solutions/webservices/pdf/SecureReliableTransactedWSAction.pdf

37. E-business Integration Patterns • The document exchange pattern • The exposed applications pattern • The exposed business services pattern • The managed public processes pattern • The managed public and private processes pattern

38. Exposed Business Services Pattern

39. Exposed Business Services Pattern • A layer between the backend enterprise system and partner tier • This layer exposes an e-business oriented interface • Business service interface to be agreed by partners • Web Services technology is an example

40. Managed Public Process Pattern

41. Managed Public Process Pattern • Private and Public processes are separated more strictly • Public processes are identified, analysed and formally described • Integration occurs at Business Process level • RosettaNet is an example • Trading Partner Agreements TPA

42. ebXML Framework • A framework of specifications for E-business integration based on state-of-the-art software architecture concepts and on experience in development of E-business systems • E-business interactions between organizations are modelled, standardised and published via E-business registries • The use of XML-based, declarative specification languages provides configurability and interoperability • Architectural separation of business and information technology aspects of e-business systems

43. ebXML and Integration Patterns • ebXML is intended to support managed public processes pattern: • Various middleware types are supported • Focus on E-business application rather application integration • Declarative definition of public business processes • Support of partner agreements

44. ebXML Modelling Methodology

45. ebXML Business Operational View • The BOV Addresses: • The semantics of business data in transactions and associated datainterchanges • The architecture for business transactions,including: • Operationalconventions • Agreements and arrangements • Mutual obligations and requirements

46. ebXML Functional Services View • The FSV Addresses: • Functional capabilities • Business Service Interfaces • Protocols and Messaging Services

47. ebXML Framework cont‘d • Business Process Specification Schema (BPSS) is an XML-based specification language that formally defines "public" business processes. It focuses on the collaboration of trading partners, and the business transaction activities they perform in the context of those collaborations.

48. ebXML Framework cont‘d • Core Components: Those provide the business information that is encoded in business documents that are exchanged between business partners. • Registry/Repository: This is useful for more than merely conducting business searches. Some business scenarios depend heavily on registries to support setting up business relationships.

49. ebXML Framework cont‘d • Collaboration Protocol Profiles (CPP) and Agreements (CPA): These are XML documents that encode a party's e-business capabilities or two parties' e-business agreements, respectively. • Transport, Routing and Packaging: The ebXML messaging services provide an elegant general-purpose messaging mechanism. The ebXML messaging service is layered over SOAP (Simple Object Access Protocol) and can transport arbitrary types of business content.

50. ebXML Business Scenario