Download Java Web Services: A Conceptual Overview

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
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.
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 servletcapable 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
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 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
53