Java Web Services: A Conceptual Overview 1. Introduction Use Application Program Interfaces (APIs)...

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


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


• 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 3.1

15

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 2.1

19

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


• 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


• 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


• 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


• 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


25

Java API for XML Registries (JAXR)

• Process of establishing a business relationshipA business posts an entry in a registryClients obtain this information from the registryClients analyze this information and determine what

services the clients want to employThe client contacts the business and negotiate access

rights to the desired servicesOnce 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


• 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


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


• 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


• 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


• 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 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

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

Java Web Services: A Conceptual Overview 1. Introduction Use Application Program Interfaces (APIs)...

Documents

Transcript of Java Web Services: A Conceptual Overview 1. Introduction Use Application Program Interfaces (APIs)...