Java Web Services: A Conceptual Overview 1

Introduction Use Application Program Interfaces (APIs) platform – building embedded applications, desktop applications, dynamic Web components, distributed systems and enterprise-class applications Portability – Can execute on any operating system and hardware platform that supports Java – This portability, along with Java's support for XML and standard networking technologies, makes Java ideal for building Internet applications 2

Introduction Java Web Services Developer Pack (JWSDP) – Version 1.0, which Sun Microsystems released in June 2002 – Includes the primary APIs and reference implementations for building Java- based Web services and clients Java XML Pack – The most important part of the JWSDP, includes Java API for XML Messaging (JAXM), v1.1, Java API for XML Processing (JAXP), v1.2 Java API for XML Registries (JAXR), v10-01 Java API for XML-based RPC (JAX-RPC), vl.0 SOAP with Attachments API for Java (SAAJ), v 1.1 3

SOAP-Based Web Services Platforms XML messaging is the foundation by which Web services clients and servers communicate – E.g., XML-RPC and SOAP A client invokes a remote Web service by creating an XML message - either a SOAP message or XML-RPC invocation The client sends the XML message via HTTP, Simple Mail Transport Protocol (SMTP) or another network protocol The transformed request is then delegated to the appropriate handling service 4

SOAP-Based Web Services Platforms 5

No standardized approaches exist for implementing Java Web services – Various platforms differ in their requirements on how a Java Web services platform – Each Java Web services platform has its own preferred way of handling deployment, performance optimization and other issues. 6

SOAP-Based Web Services Platforms Fortunately, certain Java-based Web services platforms now enable developers to preserve the implementation of Java classes that are deployed as Web services. – Enable Java classes that will be deployed as Web services to be unaware of the XML messages that clients use to invoke their published functionality – E.g., Apache's Axis, Cape Clear's CapeConnect, IONA's XMLBus 5.0, The Mind Electric's GLUE Systinet's Web Applications and Services Platform (WASP) 7

Axis A restructured successor to the popular Apache SOAP 2.2. Enables developers to create a Web services-ready platform by installing the Axis distribution on any servlet- capable application Web server Servlet – A Java technology – Extends the functionality of a server – Adheres to the request-response message model A servlet receives a request from a client Performs some function upon receiving that request Then returns a response to the client

Axis Architecture The Axis engine encompasses a network of message-processing elements. A typical interaction with an Axis Web service starts at the Transport Listener – The Axis Transport Listener receives all incoming XML messages Axis converts each XML message into a MessageContext object that represents the XML message – MessageContext object is the internal representation that Axis uses to process incoming and outgoing messages

Axis MessageContext object is sent to a chain of message handlers The MessageContext object then is sent to the targeted service's provider – Service's provider is responsible for mapping the method calls and parameters to its corresponding Java class. The corresponding provider obtains the results from the Java class, – Packages the results into a MessageContext object and sends the object to a response chain of message handlers 10

Axis The MessageContext object is processed sequentially and sent to the Transport Listener Transport Listener constructs a SOAP message from the information contained in the MessageContext object and sends the message to the receiving client. 11

Axis Platform Architecture 12

CapeConnect 3.1 Enables developers to deploy Java services, EJBs and CORBA systems in Web services environments A standalone environment that enables developers to unify legacy systems and Web services protocols without writing code – Package includes a set of graphical deployment tools, a UDDl registry and extensive documentation Provides developers with what they need to create Web services out of existing systems 13

CapeConnect 3.1 system is composed of three major components – CapeConnect Gateway The common entry-point for all client requests Forwards all client requests to the CapeConnect XML Engine servlet – CapeConnect XML Engine and Enterprise Adaptors XML Engine cooperates with Enterprise Adaptors XML Engine uses Enterprise Adaptors to convert the XML request to a Java or CORBA call Invoke the corresponding Java or CORBA service 14

CapeConnect

GLUE Standard 2.1 Provides a straightforward API designed to simplify the Web services development process The standard release provides a Web server, servlet engine and XML parser. 16

GLUE Standard 2.1 GLUE Web services platform is composed of several elements – Transport layer Receives XML messages and converts them to corresponding Java objects – Iservice implementation Act as wrapper objects that delegate all incoming XML messages to the appropriate Java class 17

GLUE Standard 2.1 The transport layer sends each Java object that corresponds to an incoming XML message to the handling IService implementation Responses are sent back to the IService, which in turn sends the response to the transport layer. The transport layer creates and sends an XML response message that contains the invocation results on the IService wrapper class. 18

GLUE Standard

Web Applications and Services Platform (WASP) Lite Provides developers with tools for implementing, testing, debugging and managing Web services. Targeted to the small-business environment 20

Web Applications and Services Platform (WASP) Lite WASP's Web services engine is composed of four levels – The XML message handling layer, – The XML message protocol support layer – A message-adaptation layer – The Java-class layer Each layer handles an aspect of the messaging process by which XML message requests are delegated to corresponding Java services. 21

Web Applications and Services Platform (WASP) Lite Each XML message is first handled by the transport layer. The XML message is then sent to a system-level interceptor layer. – Handles system-level policies that are applicable to each XML message (e.g., authentication). The system-level interceptor sends the processed XML message to the dispatcher layer, – Determines which Java service is responsible for handling the XML request. 22

Web Applications and Services Platform (WASP) Lite When the dispatcher determines the Java Web service, the dispatcher sends the XML message to the set of message interceptors associated with the Java Web service – These service-level message interceptors are particular to each Java Web service The service-level interceptors send the XML message to the XML message protocol support layer – Identifies the XML-messaging protocol of the XML message request – XML-RPC, SOAP or application-specific protocols – Responsible for creating a generic XML message that contains header and body parts. 23

Web Applications and Services Platform (WASP) Lite The XML protocol support layer then sends the XML message to the message adaptation layer – Converts the processed XML message request into an implementation- specific form that the Java service can use. Java class transmits its invocation results to the client through the chain of layers that initially processed the request. 24

Web Applications and Services Platform (WASP) Lite 25

Java API for XML Registries (JAXR) Process of establishing a business relationship  A business posts an entry in a registry  Clients obtain this information from the registry  Clients analyze this information and determine what services the clients want to employ  The client contacts the business and negotiate access rights to the desired services  Once the client and business agree on a payment method, access times and other factors, the client invokes the Web service provided by the business 26

Process of establishing a business relationship 27

Java API for XML Registries (JAXR) Architecture JAXR provider – An implementation of the JAXR API Maps JAXR objects to protocol-specific entries in the target XML registry Provides implementations of generic JAXR interfaces. Java API for XML Registries (JAXR) defines a standard architecture that enables clients to use JAXR providers to access different types of registries – E.g., those that conform to the UDDI and ebXML specifications. 28

Java API for XML Registries (JAXR) Architecture JAXR provides developers with an abstraction of concepts common to all XML registries. JAXR providers are responsible for mapping these general concepts to more specific entities within a target XML registry 29

Java API for XML Registries (JAXR) Architecture 30

Capabilities and Capability Profiles Capability – A measure by which JAXR classifies an operation an XML registry supports Capability profile – The set of capabilities supported by a given profile JAXR model enables developers to use different types of XML registries – Each type of registry supports a set of operations that are common to all registries, but also supports registry-specific operations. – Aggregates capabilities of various XML registries Developers are not limited to the set of operations that are common to all XML registries 31

JAXR The current JAXR specification defines support for two XML registry types (profiles) – UDDI registries – ebXML registries The capability profile of UDDI registries is a subset of the capability profile of ebXML registries. – JAXR providers that support the capability profile for ebXML registries also support the capability profile for UDDI registries This means that an application that is written to interact with a UDDI registry also can communicate with an ebXML registry 32

JAXR JAXR classifies an XML registry's capability set by levels. – JAXR classifies UDDI registries as level 0 and ebXML registries as level 1. 33

JAX-RPC-Based Java Web Services The Java API for XML-based Remote Procedure Calls (JAX -RPC) enables Java programmers to create and access XML-based Web services over a network A goal of RPC – Allow programmers to concentrate on the required tasks of an application - whether function calls are local or remote is transparent to the programmer 34

JAX-RPC-Based Java Web Services RPC hides information – The details that enable the application to communicate over a network – The details that perform all the networking and marshaling of data (i.e., packaging of function arguments and return values for transmission over a network) 35

JAX-RPC-Based Java Web Services RPC requires the use of a single programming language and communications protocol – Web services technology enables integration among many different languages and protocols – Using XML, HTTP, and SOAP for such integration JAX-RPC enables distributed-computing advances – By providing a clean, simple API for creating and interacting with XML-based Web services 36

JAX-RPC-Based Java Web Services Interoperability – JAX-RPC is programming-language independent and data-format independent E.g., – JAX-RPC Web service does not need to know the data formats that clients send, because client requests are sent as SOAP messages that conform to the SOAP specification – A JAX-RPC client does not need to know the Web services' underlying programming language to access the Web service, because the service's WSDL document specifies how to interact with the service 37

JAX-RPC The current release of JAX-RPC (Version 1.0) uses SOAP as the application protocol and HTTP as the transport protocol. The JAX-RPC specification defines a mapping of Java data types – E.g., int, String and JavaBeans Transform the WSDL definitions to Java types – E.g., When a client locates a service in an XML registry, the client retrieves the WSDL definition to get the service-interface definition. – The xrpcc tool, included in the JWSDP, generates Java classes from the WSDL definitions 38

JAX-RPC Features JAX-RPC enables – Java applications to invoke Web services that execute on non-Java platforms and – non-Java applications to invoke Web services that execute on Java platforms The service client needs only the WSDL to access the Web service JAX-RPC hides the details of SOAP from the developer – The JAX-RPC service/client runtime environment performs the mapping between remote method calls and SOAP messages 39

JAX-RPC Features Provides APIs for accessing Web services via – Static stubs (local objects that represent the remote services) or – Dynamic proxies ( objects that are generated during runtime), or – Invoking the Web services dynamically through the Dynamic Invocation Interface (DII) 40

JAX-RPC Architecture Service runtime-environment – A software application – Manages incoming client connections – Processes incoming and outgoing XML messages on behalf of the Web service E.g., SOAP messages – Translates incoming XML messages to simple Java method invocations, which hides the details of XML messaging from the Web-service developer Service endpoint – The Java class that implements the functionality of the Web service 41

JAX-RPC Architecture 42

Java API for XML Messaging (JAXM) Java API for XML Messaging (JAXM) Enables applications to communicate using XML-based messaging protocols such as SOAP Java Messaging APIs – The Java platform provides three different types of messaging APIs Java Messaging Service (JMS) JavaMail JAXM 43

Java Messaging Service (JMS) Enables component' to transfer messages via the point-to-point and publish/subscribe message model Point-to-point model – The sending component sends a message to a message queue – Then “forward” that message to the target – Requires that only one target component can consume messages from a message queue 44

Java Messaging Service (JMS) Publish/subscribe model – Allows zero or more subscriber to consume messages that other components publish – Uses the notation of topics (analogous to message group) – Publishers send message to a topic on a server. Clients with active subscriptions to the topic then receive those messages 45

JavaMail Enables components to send messages via Provides APIs for creating and sending mail – Determines the mailing protocols through which to send the mail – Store and retrieve mail from servers Message contains – Header Information such as From address, the To, CC and BCC address, the data – Body Actual message content Supports several Internet-mail protocols – IMAP – SMTP – POP 46

JAXM Enables components to transfer XML-formatted messages Supports synchronous and asynchronous messaging Synchronous messaging – JAXM application sends a message request to a Web service and waits for a response Appears to be identical to JAX-RPC's remote method calls – The client resumes activity only upon receiving a SOAP response from the Web service Asynchronous messaging – Does not wait for a response from the Web service – Ideal in situations where the response from a Web service invocation depends on a "human factor." 47

JAXM Asynchronous messaging – For example, a JAXM application might invoke a Web service to place an order for a product; – However, before the receiving application can notify the sending application that the order has been shipped, workers physically must transport the merchandise from a warehouse to a delivery vehicle. – This process could take an indeterminate amount of time, so it is not feasible for the sending application to wait for a response. 48

Standalone JAXM Clients and JAXM Web Services A standalone JAXM client invokes Web services synchronously – i.e., the client must wait for a response from the service A standalone JAXM client generally is not suited for providing Web services – JAXM clients are used most commonly for invoking Web services 49

Standalone JAXM Clients and JAXM Web Services 50

JAXM Application with Message Provider The client resumes activity only upon receiving a SOAP response from the Web service Since the client halts activity, the client is unable to offer Web services in conjunction with invoking another one. To circumvent this problem, JAXM applications can use a message provider. – Handles sending and receiving messages – Enabling a JAXM application to perform other functions after sending a SOAP request 51

JAXM Application with Message Provider A message provider acts as a listener for messages When the provider receives a message, the provider forwards the message to various endpoints Using a provider enables a JAXM application to send and receive messages asynchronously – Rather than sending a SOAP request directly to the Web service, the JAXM application sends the SOAP request to the message provider, which in turn sends the request to the Web service

53