1 / 53

Java Web Services: A Conceptual Overview

Java Web Services: A Conceptual Overview. Introduction. Use Application Program Interfaces (APIs) platform building embedded applications, desktop applications, dynamic Web components, distributed systems and enterprise-class applications Portability

adler
Télécharger la présentation

Java Web Services: A Conceptual Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Java Web Services: A Conceptual Overview

  2. Introduction • UseApplication 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

  3. 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

  4. 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

  5. SOAP-Based Web Services Platforms

  6. SOAP-Based Web Services Platforms • 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.

  7. 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)

  8. 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

  9. 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 MessageContextobject that represents the XML message • MessageContext object is the internal representation that Axis uses to process incoming and outgoing messages

  10. Axis • MessageContext object is sent to a chain of message handlers • The MessageContextobject 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

  11. 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.

  12. Axis Platform Architecture

  13. 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

  14. 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 andEnterprise 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

  15. CapeConnect 3.1

  16. 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.

  17. 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

  18. GLUE Standard 2.1 • The transport layer sends each Java object that corresponds to an incoming XML message to the handling IServiceimplementation • 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.

  19. GLUE Standard 2.1

  20. 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

  21. 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.

  22. 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.

  23. 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.

  24. 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.

  25. Web Applications and Services Platform (WASP) Lite

  26. 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

  27. Process of establishing a business relationship

  28. 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.

  29. 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

  30. Java API for XML Registries (JAXR) Architecture

  31. 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

  32. 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

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

  34. 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

  35. 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)

  36. 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

  37. 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

  38. 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 xrpcctool, included in the JWSDP, generates Java classes from the WSDL definitions

  39. 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

  40. 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

  41. 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

  42. JAX-RPC Architecture

  43. 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

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

  45. 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

  46. JavaMail • Enables components to send messages via email • 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

  47. JAXM • Enables components to transfer XML-formatted messages • Supports synchronousand 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."

  48. 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.

  49. Standalone JAXM Clients and JAXM Web Services • A standalone JAXM clientinvokes 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

  50. Standalone JAXM Clients and JAXM Web Services

More Related