Introduction into Web Services (WS)

Transcription

1 (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

5 Distributed Objects DCOM (COM+) Microsoft Standard Windows-dependent CORBA Object Management Group (OMG) Standard OMG vendor-neutral consortium OS and programming language neutral From

6 J2EE Distributed Components General J2EE Architecture Component communications From

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) From:

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:

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 From

17 SOAP-based Communication From

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:

19 SOAP in Action Logical View

20 SOAP in Action Deployment View Kiala SMS Infrastructure SOAP Server CN FR/NL Cancer OracleDB Server Linux Aspiro SMS Switch Outbound Proxy BT Router Reverse Proxy Production / Intranet The Internet Firewall DMZ Firewall SMS Processor CN FR/NL Cancer A. Svirskas September 17, 2002

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

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:

25 WSDL Example Real world example:

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:

28 Web Services in Operation

29 Types of Web Services From:

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:

31 Asynchronous Web Services From:

32 Web Services Examples Google.com - Amazon.com - ebay.com - Many more -

33 How do I write my own WS? Download a toolkit: IBM - Sun - Many more implementations Read a tutorial 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

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

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 data interchanges The architecture for business transactions, including: Operational conventions 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

51 A Bottom-up Approach The ebxml framework represents a topdown approach to the e-business architectures Web Services community takes a bottom-up approach based on: Proven lower layers (HTTP, SOAP etc.) A number of WS-* specifications emerging from all possible directions

52 Web Services for e-business The essence is to support long-lasting B2B collaborations, including (not limited to): Modeling of binary/multipart collaborations Validating correctness of the collaborations at design time Simulating the interactions between the peers Generating bindings to some executable mechanisms

53 Choreography Describes the allowable message flow between pairs of service end-points and composite behavior based on allowable message flows Describes peer to peer interactions of services from a neutral perspective

54 WS-CDL Web Services Choreography Definition Language - A successor to Web Service Choreography Interface - WSCI ( More on WS-CDL: ForWeb.htm Tools: and

55 WS-CDL

56 Conclusions Web Services emerged as a synthesis of RPC expertise and the Internet opportunities Web Services matured over past few years into a business-grade solution Web Services field continues to expand and reaches into e-business domain Questions, comments: Adomas Svirskas a.svirskas@kingston.ac.uk