Vous êtes sur la page 1sur 101

Developing real world Web services 

using J2ME™, J2SE™, J2EE™

Maneesh Sharma
Market Development Engineer

Sun™ Tech Days

Welcome to the two-hour session of Developing real-world Web services

using J2ME, J2SE, and J2EE.


 Web Services architecture over J2EE

 JAX-RPC architecture
 How to develop JAX-RPC based Web
 JAX-RPC client programming model
 SOAP message handler
 Document-driven model
 Real Life Web Services
 WS-I and Web Services interoperability
 Fast Web service

So this is the agenda of this 2 hour in-depth session on Web services.

First, we will talk a bit on Web services architecture over J2EE platform. Then we will
spend some time talking about JAX-RPC since JAX-RPC makes up a large chunk of
Web services support over J2EE. Then we will talk about how to develop Web
services and their clients. We will spend some time talking about SOAP message

Then we will compare RPC and document-driven model Web services talking about how
they are different and when to use what.

We will then spend some time talking about WS-I and Web services interoperability. We
will then spend last 30 minutes or so talking about various emerging Web services
technologies and standards which we believe you should be aware of. And these
include ebXML as a Business Web services standard, Fast Web service work by Sun
Microsystems, metadata-driven Web service effort driven by JSR 181, Web services
orchestration, Web services transaction, reliable messaging, and Web services security.
Since Web services security will be talked about in another session, here we will just
mention various XML and Web services security standards.

By the way, in this session, we are not going to talk about basic concept of Web services
and we assume you have some basic knowledge on what Web services is and some
basic exposure on what SOAP and WSDL are.




OK, let's talk briefly on Web services architecture over J2EE platform.

What Is a J2EE Web Service? 

 A set of endpoints (ports) operating on

 Ports are operating within a container
 Container provides runtime environment
 Contract for runtime environment are specified
in JAX-RPC, EJB 2.1, JSR 109 (Web Services
for J2EE)
 Service is described in WSDL document
and published to a registry
 WSDL specifies a contract between service
provider and client

So what is a Web service?

Under J2EE context, Web services are defined as a set of endpoints

operating on messages meaning the endpoints receive request messages
and then send back response messages. These endpoints are operating
within a container, which provides Web services runtime environment in
the same way EJB container provides runtime environment for EJB
beans. And the contract between the Web services endpoints and the
container are specified in JAX-RPC, EJB 2.1, and JSR 109.

Another aspect to note is that a Web service is described in WSDL

document and this service description can be published to a registry.
What this means is that the WSDL document is the only thing that is
needed between web service user and service provider in order to

Web Service Component and 


 Container and Component model

 Web Services components get executed within
a container
 Web Services components are portable (under
J2EE 1.4)
 Web Service components
 Web-tier (Servlet-based endpoint)
 EJB-tier (Stateless session bean-based endpoint)

Now I would like to talk about component and container model of J2EE and how it
relates to web services.

One of the key architectural characteristics of J2ee is that business logic is captured
as components, which are in turn executed in a host execution environment called
containers. And this container and component model will be used for
implementing and deploying web services as well. That is, you will build web
services as components which will be then executed in a web service container. In
other words, web services components are going to be a 1st-class citizen of J2EE
along with servlet, JSP and EJB.

Over J2EE platform, the web services components can be developed and deployed
either at Web-tier or EJB-tier. Web-tier Web services is based on Servlet endpoint
while EJB tier Web services is based on stateless session bean endpoint model.

Service Endpoint Implementation 

 Web service endpoint realized as either:

 Servlet-based endpoint
 Stateless session bean
 JAX-RPC 1.1 specifies Servlet-based
endpoint model
 JSR-109 and EJB™ 2.1 technology specify
stateless session bean endpoint model

Now as was mentioned in previous slide, Web service endpoints can be

realized as either servlet-based endpoint or stateless session bean based

Under J2EE 1.4, JAX-RPC 1.1 specifies servlet based endpoint model while
JSR 109 and EJB 2.1 specifies stateless session bean endpoint model.

Web Service Components 

Web Services

Source: Web Services for J2EE (JSR 109), V1.0

This picture shows what I just explained in the previous slide. Web services
components can reside either at web-tier or EJB-tier. When web services
component is built as a servlet-based endpoint, it is running within the
web container while when it is built as a session bean based endpoint, it
will be running within the EJb container. So you can see we are
leveraging existing container architecture for Web services components.

J2EE 1.4 and Web Services 

Service Client
J2EE App Server J2EE App Server

Client Service

Non-J2EE Non-J2EE
Service Client

Service lookup
There are two families of clients, which differ in the
way the code is written, packaged, and invoked:

Unmanaged clients J2EE container-managed clients.

Here, unmanaged means not J2EE container
managed. These are Java 2
Standard Edition (J2SE) clients and are invoked with
a simple java command. For unmanaged clients,
the service lookup is through the JAX-RPC
ServiceFactory, a factory for the creation of
instances of services access points. For J2EE
container-managed clients, service lookup is
through JNDI lookup.




JAX-RPC Features 

 Servlet-based Web service endpoint

 WSDL to/from Java™ mapping
 XML data types to/from Java™ types
mapping (serialization)
 Extensible type mapping
 SOAP Message Handler framework
 Client Programming Models

What is the scope of JAX-RPC?

First,JAX-RPC also defined servlet-based web service endpoint model.
JAX-RPC also defines how a WSDL document and its elements are to be mapped into Java™
representations. For example, the portType element of WSDL document will be mapped
into what is called Web services endpoint interface, which is Java™ representation of the
abstract definition of the service.

It also defines how Java™ and XML data type mapping is to be done. That is, when a SOAP
client invokes a RPC method, the parameters of the method which are in the form of Java™
objects have to be mapped to XML elements. Also on a server side, a SOAP service
provider when it receives a SOAP RPC request message, it has to in turn map the XML
elements into Java™ objects.

JAX-RPC provides extensible type mapping framework in which complex Java™ data types
can be serialized and deserialized from corresponding XML representations.

JAX-RPC also introduces the concept of SOAP message handler framework in which message
handers can be chained and deployed during the deployment time not at the time of
development time. What is message handler? It intercepts incoming SOAP message
request and outgoing SOAP message responses and perform whatever functions necessary,
for example, authentication, authorization, logging, caching, or whatever.

JAX-RPC also defines client programming models which include stub interface, dynamic
proxy, dynamic invocation depending on how dynamic you want to code your client side.

Inside a SOAP Message 

SOAP Message SOAP Envelope

SOAP Header
Primary MIME Part
Header Entry

Header Entry
Body Entry

Body Entry

This picture shows SOAP message. As illustrated in the left side of the
slide, a SOAP message is made of Primary mime part and zero or more
attachments. The primary mime part contains SOAP envelope structure,
which in turn is made of Header part and Body part. And both Header
and Body parts can be made of multiple header entries and body entries

WSDL View of a Web Service 

WSDL Document
Service A
Binding "fooB"
Port "foo"
http://.../foo SOAP/HTTP

Port "bar"

Port "xyz" Port Type "fooPT"

Operation "Op1"

Service B Operation "Op2"

Port ...

This picture shows internal structure of a WSDL document. A WSDL

document can be made of multiple Services. Each Service is a collection
of ports. A port represents end result of a concrete binding between
abstract description of a service and concrete transport protocol and port
address. The abstract description of a service is represented as a porttype.
A porttype is a collection of operations. And each operation is an action
which is made of input and output messages.

Example: WSDL 


<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>


<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>

WSDL Elements

Service Types
Class 1..n
1 1
PortType Binding

Operation 1..n
Method Parameters

JAX-RPC Relationship to WSDL 

JAX-RPC describes a Web Service as a

collection of remote interfaces and methods

Tools are used to convert between WSDL

documents and sets of Java™ remote

WSDL describes a Web Service as a

collection of ports and operations

I mentioned already WSDL is the contact between Web service client and
service. I also mentioned that JAX-RPC specification defines the precise
mapping between WSDL and its corresponding Java™ representation.
Because this mapping is precisely defined in the JAX-RPC specification,
typically this mapping is done using a tool.

And you will see this when we do the demo later on.

Service Description 

JAX-RPC specifies the standard

WSDL<->Java mapping:
<portType name="StockQuoteService">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
public interface StockQuoteService
extends java.rmi.Remote {
public String GetLastTradePrice(String s)
throws java.rmi.RemoteException;}

JAX-RPC Architecture Diagram 

Client WSDL Document Service Endpoint
Generated Code

Container Container

Client-side JAX-RPC Server-side JAX-RPC

Runtime System Runtime System



This picture shows JAX-RPC architecture In both client and server side,
there are JAX-RPCruntime systems which are provided by containers.

Again, in the server side, the container will be either Web container or EJB
container depending on whether you are building servlet based or EJB
based endpoint. On the client side, the container could be typically just
collection of jar files.

As was mentioned before, the contract between Web services client and
service is via WSDL document. What this means for the client side is
that from the WSDL document, the container or deployment tool can
generate client side code artifacts such as stub object.

When I say WSDL document is the only contact needed by service provider
and service client, I really mean it.




#  $! %



" !




Now let's talk about how to develop a JAX-RPC based Web service. We are
going to focus on Web-tier here but pretty much the same process can be
applied to developing EJB stateless session bean based Web service.

Developing a Web Service 

(Bottom-up approach)

Interfaces (java.rmi.Remote)
Must follow JAX-RPC conventions

Implementation classes
Servlet-based endpoint model
Optional handler classes

tool WSDL Service contract

Packaged application (war/ear file)

There are several different approaches in developing a Web service. For

example, you can take top-down approach or bottom-up approach. In
top-down approach, you define WSDL document first and then do the
service implementation. In Bottom-up approach, you create
implementation, first then WSDL document.

So in bottom-up approach which is shown here, you create service interface

which is java.rmi.Remote type and you create service implementation that
is the type of the service interface. Or in practice, you can create service
interface from the service implementation, which we will show as a demo
later on.

And then create a package which is in the form of WAR file for the Web-
tier Web services.
Example: Interface

package hello;

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface HelloIF extends Remote {

public String sayHello(String s) throws RemoteException;


So this is an example service definition interface. The

name of the service is HelloIF. Note that it extends
java.rmi.Remote. And the methods throw

If you notice a similarity between service definition

interface and a remote interface of EJB beans, you are
correct. They are in fact quite similar.
Example: Implementation

package hello;

public class HelloImpl implements HelloIF {

public String message = new String("Hello ");

public String sayHello(String s) {

return new String(message + s);


This is an service implementation. Here you should note that the service
implementation implements the service interface which you saw in the
previous slide.
Deployment Descriptor
<description>Hello Servlet</description>

Generated by deployment tool


This is an service implementation. Here you should note that the service
implementation implements the service interface which you saw in the
previous slide.
&   !

Public interface Greeting extends remote {

public String sayHello(String name) Endpoint
throws RemoteException; Interface

public class GreetingBean implements SessionBean {

public String sayHello(String name) Stateless
throws RemoteException {
return "Hello" + name;
} Bean Class

<session-type>Stateless</session-type> Deployment
. . . Descriptor


Packaging and Deployment 

 Extension of Web-tier (WAR) or EJB-tier

(EJB Module) packaging
 JSR-109 specifies standard deployment
descriptor under J2EE 1.4
 Actual runtime model is container-specific
 Tools simplify packaging and deployment:
Ant scripts, GUI wizards, IDE plug-ins

Now let's talk about packaging and deployment of Web services over J2EE
platform. Basically Web services components are packaged either as
Web-tier WAR file or EJB-tier EJB module.

Under J2EE 1.4, JSR 109 defines standard deployment descriptor. And the
actual Web services runtime environment is container specific. And it is
expected that tools will simply packaging and deployment through ant
scripts and GUI wizards and IDE plug-ins. And you will see what I mean
when we give you a Web services development and deployment demo
later on using Sun ONE Studio 5.

Packaging of 

JAX-RPC API-Based Applications

Web Application (WAR file)

WSDL (optional)

Deployment Descriptor

Service Handlers/
Implementation serializers

JAX-RPC based Web service is packaged as a WAR file with all the necessary
compnents, for example, service implementation which are either Java™
classes for sevlet endpoint model, handler classes and WSDL document, and
Web service definition interface, which isJava™ abstract representation of the
WSDL document. This packaging is standardized in J2EE 1.4.
And in the hands-on lab, you will see how a web services is packaged and

Java Web



Developer Pack 

'(   #) 

   ' % 
, ---
 . ! . /  . "

'  )  *




Client Programming Models 

 Stub-based (least dynamic)

 Both interface (WSDL) and implementation (stub)
created at compile time
 Dynamic proxy
 Interface (WSDL) created at compile time
 Implementation (dynamic proxy) created at
 Dynamic invocation interface (DII)
 Both interface (WSDL) and implementation
created at runtime

Now JAX-RPC defines three different client programming models – stub

based, dynamic proxy based, and dynamic invocation interface based. You
choose one of these three programming models depending on how flexibily
you want to write your client programs.

Stub-based programming model is the least dynamic in the sense that the Stub
object has to be created at the time of compile time and both WSDL and
interface has to be known at the compile time.

Dynamic proxy programming model still requires WSDL at the time of compile
time but the interface can be fed at runtime

Finally in DII programming mode, neither WSDL nor interface is required

during runtime so this is the most dynamic way of writing client side code
but it is the most complex code and thus reserved only for advanced
programmers. Because client does not need to know WSDL, DII
programming model supports what is called broker model in which client
can ask broker to find best web service based on some search criteria.

Stub-based Invocation Model 

 Stub class gets generated at compile time

 All needed value classes are also generated
 Instantiated using vendor-generated Service
implementation class
 Stub class is bound to a specific XML protocol
(i.e. SOAP) and transport (i.e. HTTP)
 Best performance
 Stub class implements
 Javax.xml.rpc.Stub interface
 Web service definition interface

Now let's talk about stub based programming model first.

In this programming model, the stub class gets generated from WSDL at
compile time.
The stub object instance gets generated from a factory class class Service class,
which we will talk about later one more time.
Stub object is bound to a particular XML and transport protocol. So if the
service is deployed over different transport protocol such as SMTP, the a
new stub has to be generated.
Compared to dynamic proxy and DII model, stub based programming gives the
best performance.
Finally the Stub class has to implement two interfaces – the first is
javax.xml.rpc.Stub interface and the other is Web service definition interface
for that particular web service.

Stub Class Hierarchy 

<<interface>> <<interface>>
javax.xml.rpc.Stub com.example.stockQuoteProvider


This picture shows the Stub class hierarchy. As was mentionedin the previous
slide, the Stub class that gets generated by the tool will implement two
interfaces, javax.xml.rpc.Stub interface and then actual Web service
definition interface.
In this example, the Web service definition interface is called

Standalone Stub-based Client 

package hello;

public class HelloClient {

public static void main(String[] args) {

try {

HelloIF_Stub stub = (HelloIF_Stub)

(new HelloWorldService_Impl().getHelloIFPort());

System.out.println(stub.sayHelloBack("JAXRPC Sample"));
} catch (Exception ex) {

This is an example code in which dynamic proxy is generated. Here weget

Service object first, which functions as a factory class for generating
dynamic proxy object. That is, once we get Service object from
ServiceFactory class, we can then get dynamic proxy object by passing
WSDL document and Web service definition interface as parameters.
Once you get the dynamic proxy object, then you can invoke a method,

J2EE Stub-based Client 

package hello;
import javax.xml.rpc.Stub;
public class HelloClient {

public void callSayHello{

try {

Context ic= new InitialContext();

Service service =(Service)
HelloIF hello

} catch (Exception ex) {


J2EE container-managed clients

use Java Naming and Directory Interface (JNDI) instead to obtain a
Service Interface.
This is a two step process:

1)Instantiate a local JNDI Context.

2)Do a JNDI lookup for the Web service name in this context.

The Service Interface obtained is then used to get a static stub,

dynamic proxy, or a DII Call object.

The code in this method is implementation-specific because it relies on a

MyHelloService_Impl object, which is not defined in the specifications. The
MyHelloService_Impl class was generated by wscompile
Obtain a stub.
Invoke the Web service's operations on the stub.
The stub method uses a platform-specific stub created before runtime during the
WSDL to Java mapping stage. Because the stub is created before runtime, it is
sometimes called a static stub. It is a Java class implementing the SEI. A
WSDL to Java mapping tool generates the client-side artifacts needed;
basically, the tool imports the WSDL service definition and creates the
corresponding Java code. The artifacts include an SEI, a Stub, and optionally
holders, serializers, deserializers, and utility classes. JAX-RPC recommends
an instance of a stub to be bound to a specific protocol and transport, such as a
SOAP binding stub.

Dynamic Proxy-based 

Invocation Model
 At Runtime Application provides the WSDL
 Dynamic proxy is generated on the fly
by JAX-RPC client runtime
 More portable than stub-based:
 Does not depend on vendor generated service class
before runtime
 Easiest to program but slower
than stub-based
 Implementation object created and casted

Now dynamic proxy is generated on the fly by JAX-RPC client runtime system.
And application provides the Web service definition interface during runtime.

The advantage of using this method is that

you write portable, vendor-independent code. However, you need to know
the WSDL URL at development-time and you need to run your WSDL to Java
mapping tool against the WSDL document before runtime. If you do not
have this information, or if the WSDL URL is likely to change, you
should use the DII method instead.

!  0 %  /% 


01 package proxy;
02 import java.net.URL;
03 import javax.xml.rpc.Service;
04 import javax.xml.rpc.JAXRPCException;
05 import javax.xml.namespace.QName;
06 import javax.xml.rpc.ServiceFactory;
07 public class HelloClient {
08 public static void main(String[] args) {
09 try {
10 String UrlString=
11 String nameSpaceUri = "http://proxy.org/wsdl";
12 String serviceName = "HelloWorld";
13 String portName = "HelloIFPort";
14 URL helloWsdlUrl = new URL(UrlString);

!  0 %  /% 


15 ServiceFactory serviceFactory =
Service helloService =
18 serviceFactory.createService(helloWsdlUrl,
19 new QName(nameSpaceUri, serviceName));
20 HelloIF myProxy = 2
(HelloIF) helloService.getPort(
21 new QName(nameSpaceUri, portName),
22 proxy.HelloIF.class);
23 System.out.println(myProxy.sayHello("Duke"));
24 } catch (Exception ex) {
25 ex.printStackTrace();
26 }
28 }
} 3

Dynamic proxy
From a JAX-RPC Service, you can use a proxy to invoke the Web
service's operations. The proxy is a Java class implementing the SEI.
A proxy is obtained with the JAX-RPC Service's getPort() method, which
takes the name of the port for the Web service you want to invoke
(found in the WSDL document), as well as the SEI implemented by the
proxy. It is called dynamic because the proxy is created at runtime.
The steps for dynamic proxy clients are:

Get a JAX-RPC Service.

Obtain a proxy using the JAX-RPC Service's getPort() method in order
to invoke the Web service's operations.
In step 1, for unmanaged clients, a JAX-RPC Service is obtained from
the JAX-RPC ServiceFactory by passing the WSDL URL as well as the
service name parameter to the createService() method. For J2EE
container-managed clients, you get a JAX-RPC Service from JNDI lookup.
Listing 5 shows the dynamic proxy method (step 2) to invoke the
"getGreeting" operation on the Web service.

DII Invocation Model 

 Gives complete control to client programmer

 Most dynamic but complex programming
 Could combine with UDDI lookup and WSDL
parsing for dynamic lookup and discovery
 Used when service definition interface is not known
until runtime
 Has to create Call object first
 set operation and parameters during runtime

DII invocation model gives the most flexible way of performing service
invocation by giving complete control to client programmer. And as was
mentioned, DII supports broker model.
In order to use DII invocation model, you have to create Call object first.
With this method, you do not need to know the
WSDL URL at development-time.
Making DII calls through a Call object is programmatically more
complex than using a stub or dynamic proxy. However, the advantage of
using a DII Call interface is that a client can call a remote
procedure without development-time knowledge of the WSDL URI or the
Web service operations' signatures. This makes the code easy to modify
if the Web service details change. With DII clients, runtime classes
generated by WSDL to Java mapping tools (emitters) are not required
like the dynamic proxy or static stub cases. However, if you know the
Web service you want to invoke is unlikely to change, you should use
dynamic proxy because configuring the Call instance can be complex.

Example: DII Client 

package dynamic;

import javax.xml.rpc.Call;
import javax.xml.rpc.Service;
import javax.xml.rpc.JAXRPCException;
import javax.xml.namespace.QName;
import javax.xml.rpc.ServiceFactory;
import javax.xml.rpc.ParameterMode;

public class HelloClient {

private static String endpoint =

private static String qnameService = "Hello";
private static String qnamePort = "HelloIF";

private static String BODY_NAMESPACE_VALUE =

private static String ENCODING_STYLE_PROPERTY =
private static String NS_XSD =
private static String URI_ENCODING =

And this slide and next slide shows example code of DII based Web services

Standardalone: DII Client 

public static void main(String[] args) {

try {
ServiceFactory factory = ServiceFactory.newInstance();
Service service = factory.createService(new QName(qnameService));
QName port = new QName(qnamePort);

Call call = service.createCall(port);


call.setProperty(Call.SOAPACTION_USE_PROPERTY, new Boolean(true));

QName QNAME_TYPE_STRING = new QName(NS_XSD, "string");
call.setOperationName(new QName(BODY_NAMESPACE_VALUE "sayHello"));
call.addParameter("String_1", QNAME_TYPE_STRING, ParameterMode.IN);
String[] params = { "Duke!" };

String result = (String)call.invoke(params);


} catch (Exception ex) {


As you can see in this code, we create Call object from Service object and then
fill up the method and parameters during runtime.
Comparison of Three Client 


" %  /% %  


































SOAP Message Handlers 

 Handlers let you access/modify SOAP

request and response messages
 Typically used to process service contexts in SOAP
header blocks
 Can be used to extend functionality of Web Services
runtime system
 J2EE containers (which provide Web Services runtime) are
likely to use them internally to provide session/transaction
 Example handlers: Encryption, decryption,
authentication, authorization, logging, auditing, caching

SOAP mesasge handlers let you intercept incoming SOAP request and
response mesasges and peform custom functions such as encryption,
decryption, authentication, authorization, logging, caching and so on.

In our hands-on lab, you will build and deploy both server and client side
SOAP message handlers.

SOAP Message Handlers 

 Pluggable and chainable

 Through standardized programming API
 Portable across implementations
 Has its own life-cycle
 JAX-RPC runtime system calls init(),
destroy() of a handler
 Handler instances can be pooled
 MessageContext is used to share properties
among handlers in a handler chain

SOAP message handlers are pluggable and chainable. On the client side,
the registration and configuration of SOAP message handlers are done
through standardized programming APIs, which allows portable
handler configuration and registration.
Handlers have their own lifecycles, which are managed by the containers.
In fact, handler instances can be pooled for scalable operations.
Handlers also have access to MessageContext object in which share'able
data mong handlers can be maintained.

SOAP Message Handlers 

SOAP Message Handler Chain

Handler Handler Endpoint (Port)

SOAP Message

This picture shows how multiple handlers can form handler chain. Here SOAP request
message is intercepted by handler # 1. Handler #1 peforms some handler logic and then
pass the request to the handerl #2, which performs its own handler logic and then it passes
the request to the service endpoint.
And response message then goes through the handler chain in reserve order. Again, this chain of handlers is
configured at the time of deployment and at the client side, it can be configured during runtime.

Example SOAP Message Handler 

package com.example;

public class MySOAPMessageHandler implements

javax.xml.rpc.handler.Handler {
public MySOAPMessageHandler() { ... }
public boolean handleRequest(MessageContext context,
HandlerChain chain){
try {
SOAPMessageContext smc = (SOAPMessageContext)context;
SOAPMessage msg = smc.getMessage();
SOAPPart sp = msg.getSOAPPart();
SOAPEnvelope se = sp.getEnvelope();
SOAPHeader sh = se.getHeader();
// Process one or more header blocks
// ...
// Next step based on the processing model for this handler
catch(Exception ex) {
// throw exception
// Other methods: handleResponse(), handleFault(), init(),

This slide shows an example handler code. Your custom handler class
implementsHandler interface, which has HandleRequest and
HandleResponse() methods. In this code, we get SOAP message
header object first and then performs whatever handler logic that is
appropriate. The key point is that the handler has a full access to the
SOAP message.




Session Management 

 JAX-RPC runtime system manages session

 Service client or service developer do not have to
deal with session management
 Supported session management schemes
over HTTP
 URL rewriting
 SOAP header-based session management
scheme in the future

JAX-RPC 1.0 specification requires that a service client be able to participate in a session
with a service provider. The underlying JAX-RPC runtime system manages session
without involving service client or service developer in the details of session

A JAX-RPC 1.0 runtime system is required to use at least one of the following
mechanisms to manage session for a service client. These session management
mechanisms assume HTTP as the transport in the protocol binding. A JAX-RPC 1.0
runtime system may use HTTPSession to implement support for session

Cookie based mechanism: On the initial method invocation on a service, the server side
JAX-RPC runtime system sends a cookie to the service client to initiate a new session.
The client side JAX-RPC runtime system then implicitly sends the cookie for each
subsequent method invocation on this service. The cookie associates subsequent
method invocations from the service client with the same session.

URL rewriting involves adding session related identifier to a URL. This rewritten URL is
used by the service provider to associate a request with a session. The URL that is
rewritten depends on the protocol binding in use.

SSL session is used to associate multiple remote method invocations as part of a session.




 HTTP basic authentication support is

 Certificate based mutual authentication
using HTTP/S (HTTP over SSL)
 J2EE 1.4 mandates it
 Does not require support for SOAP
Security Extensions for digital signature
 J2EE 1.4 does not mandate it but vendor products
will support it (Java WSDP 1.2 supports it now, Sun
ONE App Server 8 will support it in the future)

JAX-RPC 1.0 specification requires that a service client be able to authenticate

to the service provider. This slide specifies requirements for different
authentication mechanisms when HTTP or HTTP/S is used as the underlying

JAX-RPC 1.0 specification requires support for HTTP Basic Authentication for
bindings over the HTTP transport. HTTP Basic Authentication uses user name
and password for authenticating a service client. During invocation of a remote
method, HTTP server (considered part of a JAX-RPC server side runtime
system) uses user name and password to authenticate the service client. The
authentication is performed in a specified security realm.

JAX-RPC 1.0 specification does not require support for the certificate based
mutual authentication using HTTP/S (HTTP over SSL) mechanism but since
j2EE 1.4 mandates it, it will be there for most app server products.

JAX-RPC 1.0 specification nor J2EE 1.4 does not require support for SOAP
Security Extensions for digital signature. But since XML digital signature and
encryption are now standards, it is expected most vendor products will support
it. Just to let you know, Java WSDP 1.2 supports XML digital signature and
encryption right now.

Security Layers – Transport Layer 

 Transport level security

 Basic Authentication
 the Web server will authenticate a user by using the
user name and password
 Part of JAX-RPC 1.0 spec

 Client-Certificate Authentication over

 Web service application for client-certificate
authentication over HTTP/SSL

Transport Layer – Server 

 Start with unsecured JAX-RPC servlet-

based endpoint
 Add security constraints to servlet web.xml
deployment descriptor (DD)
 Generate server artifacts
 Deploy on servlet container

Transport Layer – Client 

 Start with unsecured JAX-RPC client

 Add code to set standard JAX-RPC proxy Stub
 Server endpoint HTTPS URL to connect to



Example: HTTP



StockQuoteService sqs = getStockQuoteService(..);

// Get the instance of stub object setting username & password

StockQuoteProvider sqp = sqs.getStockQuoteProviderPort(
float quote =

This slide is an illustrative example of a service client accessing a service

port bound to the HTTP transport. The user name and password passed in
the getStockQuoteProvider method are used for authenticating the service



J2ME and
Web Services

Now let's talk about how J2ME devices can perform Web service invocation.

JSR-172 (J2ME Web Services) 

 J2ME Web services client

JSR – 172


J2ME device Web Services

The purpose of JSR-172, J2ME Web services specification, is to define an optional

package that provides standard access to web services from J2ME devices.

The specification basically defines two things. First, parsing, that is, how to
manipulate structured XML data over J2ME platform, and this will be a subset of
JAXP. And the other is how J2ME can function as a Web services client, which
is subset of JAX-RPC.

JAX-RPC Subset of JSR172 

 Subset of JAX-RPC 1.0

 Additionally specifies runtime
SPI-portable stubs
 No support for the service endpoint model.
The subset only provides support for clients
to access web service endpoints.
 Alignment with WS-I Basic Profile
 Protocol encoding: SOAP 1.1 using XML
based protocol

So as I said, JSR 172 extracts a subset of JAX-RPC functionality that is relevant to

J2ME devices.

JSR 172, however, specifies runtime Service Provider Interface to allow portable
stubs as opposed to non-portable stubs of regular JAX-RPC.

Again JSR 172 is only for client side functionality. That is, JSR 172 does not define
how J2ME devices can be service endpoint.

JSR 172 is well-aligned with WS-I basic profile. The version of SOAP it supports is
SOAP 1.1.
Wireless Webservice Clients (MIDP 


 MIDP clients are supported through:

 Generation of appropriate SOAP proxy from
(example: KSOAP) from a service's WSDL
 Generation of appropriate JAX-RPC client subset
(using JSR-172)
 Webservice clients will be applications on
the devices – example: MIDlets
 Sun Java Studio Mobile Edition – nice tool
for developing, packaging, and testing





Now let's talk about document style web services.

RPC vs. Document-driven 

RPC Document-driven

 Procedure call  Business documents

 Method signature  Schema
 Marshalling  Parsing & Validating
 Tightly-coupled  Loosely coupled
 Point to point  End to end
 Synchronous  Asynchronous
 Typically within  Typically over internet

Web services can be implemented in two different models - RPC model and document-
driven model.

The RPC model simulates a procedural call between Web service endpoint and its client
while under document-driven model, the business documents are exchanged. Under
RPC model, a thing that has to be agreed upon between service provider and client is
method signature such as method name and a set of parameters and their types while
under document-driven model, the schema of the business documents need to be agreed
upon. And under RPC model, the parameters and return values have to be marshalled
and unmarshalled while under document-driven model, the XML documents need to be
parsed and validated.

Because agreeing upon method signature is considered more stringent, RPC model is
considered more tightly coupled than document-driven model. For example, if the
service adds another parameter, the client needs to be changed under RPC model.

The RPC model always works in synchronous mode in that the sender of the message
waits for the response while messaging model supports both synchronous and
asynchronous model.

It is expected that RPC model will be more or less used within a business organization
while document-driven model would be used over the internet between business
organizations because document-driven model is more loosely-coupled than RPC

When to use
RPC vs. RPC and

When to use Document-driven?

RPC Document-driven

 Within Enterprise  Between enterprise and

 Reliable and high  Unpredictable
bandwidth bandwidth
 Short running business  Long running business
process process
 Trusted environment  Blind trust

So when do you want to use RPC model and when do you want to use
document-driven model Web services?

The rough guidelines is to use RPC model within an enterprise and to use
document-driven model for enterprise to enterprise communication. It is
because document driven model allows a bit more loosely coupled model.

And since

Document-Driven Model using 


 Use of “document/literal” SOAP message

(instead of “RPC/encoding”)
 SOAP body contains XML document, i.e.
Purchase order
 Specified via “style” and “use” attribute in WSDL
 Use of Attachments
 Attachment contains XML document
 Specified via MIME binding in WSDL document

So how do you implement document-driven model Web services using JAX-

RPC? There are two different ways of doing it. First, you can use
“document/literal” SOAP message. In this case, the SOAP body contains
XML document, for example, purchase order. The doc/literal is specified
via style and use attribute in WSDL document.

The 2nd way of implementing document-driven model is the usage of

attachments. In this method, the attachments contains XML document.
And these attachments are specified using MIME binding in WSDL

Document-Style WSDL 

 WSDL provides a document-style service

contract between sender and receiver
 Abstract Message Description
 Provides name for each part: PARTNAME
 Provides type of each message part
(e.g., schema for XML parts)
 Binding Description
 Provides messaging packaging format

So in your WSDL document, you can specify that you want doc/literal style.

Document-Style SOAP 

Header Envelope
 Specifies message-
level services Header

Security Header

Payload Routing

 Schema-defined Body
 Large Order
 Complex Body

SOAP Attachments and Literals 

Attachments Literals

• Very non-restrictive • XML doc/structure

embedded in SOAP
– XML body
– Non-XML • JAX-RPC parses XML,
javax.activation.DataHandler creates java objects
• Parse-your-own • Obtains service
or use JAXB information from WSDL
• Several XSD elements
optional - may not be
implemented by some





Now let's talk about document style web services.

 Services & J2EE tiered




+ + &
       * %

 ' & 

1 ' '

  &"  *

'  * 1 ! *  " 
  *    2 

Synchronous Web services are architected using a JAX-
RPC servlet endpoint. The servlet endpoint receives the
client's request and then delegates the request to the
service's appropriate business logic, which may reside in
the service's Web tier or Enterprise JavaBeansTM (EJBTM)
tier. The service's business logic processes the request. It
may access the business data through a persistence
mechanism, if required. When it completes its processing,
the service's business logic formulates a response and the
JAX-RPC servlet endpoint returns the response to the
client. A synchronous architecture such as this is also
suited to expose a Web service interface to an existing
J2EE application that may already have a browser,
wireless client, or rich client interface. In such a case, the
Web service interface becomes another view (or
presentation of) the existing J2EE application.
The Java Pet Store supplier sample application is
another example of a document-oriented service that
works well with asynchronous communication.
(shows how an asynchronous Web service might be
architected. This figure shows one recommended
approach for architecting a Web service to achieve
asynchronous communication in the J2EE 1.3
setting. In this architecture, the client sends a request
to the JAX-RPC servlet endpoint on the Web
container. The servlet endpoint delegates the client's
request to the appropriate business logic of the
service. It does so by sending the request as a Java
Message Service (JMS) message to a designated
JMS queue or topic. The JMS layer (along with
message-driven beans) makes asynchronous
communication possible.Message-driven beans in
the EJB tier read the request and initiate processing



Mars Rovers Mission 

Collaborative Information Portal

 Provide a central place to
access mission information
 Provide a Mars time clock
 Navigate, search, and view
mission data, plans, reports
and schedules from various
 Provide notification of
updates of various mission

Collaborative Information Portal (CIP) 


 Java Application
 Middleware (Web Services and Enterprise
 Database (Oracle)
 Loader (Java Application)
 Monitor (Java Application)

Middleware Solutions

 Use Web Services to expose the remote

methods of the service provider EJBs
 Support both Java and C++ client applications
 Use SSL for encryption.
 Use Enterprise JavaBeans (EJBs) to achieve
reliability, scalabilty, security, platform
independence, and standards
 Stateless session beans are service providers.
 Stateful session beans cache data.
 Use the Java Message Service (JMS) for
 Broadcast messages and event notification
 Message-driven beans manage message archiving

Middleware Architecture 

I J2EE Application Server
Web E
Application W
Service HTTPS
Java A
Client Stub
Service Provider
Processor Remote Stateless
Session EJB
Client Stub

Web I
SOAP Service Provider
Service R Remote Stateless
C++ HTTPS Processor
Client Stub E Session EJB

• Web Services expose the • HTTPS encrypts the

remote methods of the transmissions and gets them
Service Provider EJBs. through the firewall.

Caching Data 

F J2EE Application Server

I Data
R Local Stateful
E Session EJB
Java JD B
L Service Provider Data
Service HTTPS Remote Stateless Local Stateful JDBC Database
Client Stub Session EJB Session EJB

F Local Stateful
I Session EJB
L Cache

• The Cache Registry keeps track of which Data EJBs are in memory.



& '

&  #
Now let's talk about WS-I and Web services interoperability.

WS-I Is 

“An open industry effort chartered to promote

Web Services interoperability across platforms,
applications, and programming languages.

The organization brings together a diverse

community of Web services leaders to respond
to customer needs by providing guidance,
recommended practices, and supporting
resources for developing interoperable Web

First, let me clarify what WS-I is first. WS-I is an open industry effort
chartered to promote Web services interoperability across platforms,
applications and programming languages.

It also provides guidances, recommendation practices for interoperability.

WS-I Is Not 

 Is not a source of WS-* specs

 These have typically been proprietary specifications
from single or small groups of companies, though a
few have been submitted to recognized standards
 Is not a ‘standards’ organization
 Doesn’t produce specs for new technology
 Profiles existing specifications

Let me tell you what WS-I is not as well since there seems to be some
confusion about this.

WS-I is not a source of WS-* specifications. WS-* specifications are in

fact proprietary specifications from a single or small group of
companies even though some of them were submitted to standard

WS-I is not standards organizations. That is, it does not produce an

standard specifications for new technologies. Instead, it creates
profiles for existing specifications mainly for interoperability.

Basic Profile 1.0 

 SOAP 1.1, WSDL 1.1 and UDDI 2.0

 Consists of 156 conformance requirement

 48 related to SOAP
 84 related to WSDL
 8 related to UDDI
 6 related to security

The first piece of work from WS-I is basic profiles.

Basic profile 1.0 profiles conformance requirements in SOAP 1.1, WSDL 1.1,
and UDDI 2.0. Basic profile 1.0 is made of 156 conformance

Basic Profile 1.1 

 Adds support for attachments to Basic

Profile 1.0
 Based on
 SOAP+Attachments W3C Note (MIME)
 WSDL MIME Binding

Basic profile 1.1 adds support for attachment to the basic profile
1.0. It is based on SOAP with attachment W3C note and
WSDL MIME binding.

WS-I Support in J2EE 1.4 

 Package WS-I BP 1.0-conforming WSDL

documents in your J2EE™ 1.4 application
 Containers will take care of all the details:
 HTTP 1.1 requirements
 SOAP 1.1 requirements
 WSDL 1.1 requirements
 UDDI 2.0 requirements (if supported)

J2EE 1.4 supports WS-I basic profile 1.0. If you package basic
profile 1.0 conforming WSDL document, the container will take
care of all the details in terms of creating conforming SOAP
messages with conforming encoding styles.

Supply Chain Management 

Sample Application


Configurator Warehouse A Manufacture A

Retailer Retailer Warehouse B Manufacture B

Web Page

Warehouse C Manufacture C

As a way of making sure actual implementations from different vendors interoperate, WS-
I also defines a sample application which is made of 9 Web services. All the vendors
are expected to implement these sample Web services endpoints and then expose them
as Web services over the internet.

WS-I Sample App is a simple Supply Chain Management application. The application
being modeled is that of a Retailer offering Consumer electronic goods to Consumers;
a typical B2C model.

To fulfill orders, the Retailer has to manage stock levels in Warehouses. When an item in
stock falls below a certain threshold, the Retailer must restock the item from the
relevant Manufacturer's inventory; a typical B2B model. In order to fulfill a Retailer's
request, a Manufacturer may have to execute a production run to build the finished

Each use case includes a logging call to a monitoring system in order to monitor the
activities of the services from a single monitoring service.

Optionally, there is a Configurator web service that lists all of the implementations
registered in the UDDI registry for each of the web services in the sample application.

I already mentioned the sample application is made of 9 Web services. And these are 1
Retailer, 1 Logging Facility, 3 Warehouses, 3 Manufacturers and 1 Configurator, and
thus a total of 9 web services.

Sample Application Flow 

www.WS-I.org www.WS-I.org

Welcome SampleApp

www.vendorX.com www.vendorX.com www.vendorX.com www.vendorX.com

Configuration ShoppingCart OrderStatus TrackOrder

(this slide is hidden)

WSDL Descriptions 

This is the WSDL description of each Web service endpoint. As you can see, each
service is configured with different set of possible values so that interoperability
can be tested. So they use different calling convention, uses either rpc/literal or
doc/literal as encoding style. Different data types are used for different endpoints.
And usage of SOAP field or not can be also tested.

Monitor & Analyzer 



Log File Analyzer Results

WS-I also provides two testing tools - monitor and analyzer. The monitor captures
the SOAP messages that are being exchanged between Web service provider and
its client and logs them into a log file.

The log file is then analyzed by the analyzer and you can see if the SOAP messages
are in fact conformant to the WS-I basic profile or not.

Monitor Can Live Anywhere 

Requestor Monitor Requestor

Service Machine B Machine A

Machine A
Machine B
Service Requestor
Monitor Service
Machine A
Machine A Machine B

The monitor captures the SOAP messages as “a man in the middle”. And it can
reside pretty much anywhere. This slide shows different ways of placing the

First in the picture on the upper left corner, both service and its client reside in a
single machine while the monitor resides in a different machine. In the picture
on the upper right corner, client and service provide reside in two different
machines and the monitor resides on the server side. And on the lower right
corner, the monitor resides on the client side. The lower left conner shows a case
where service, client, and monitor all reside in a single machine.

The demo that I will show you will use the configuration of red, in which the
service client and monitor resides on a Sun workstation here while we are
accessing remote Web services endpoints over the internet.


Analyzer Document
Confg File

Message Document


The analyzer can take various pieces of information as inputs and then generates a
conformance report which then can be transformed into HTML document. The
inputs can be WSDL document, UDDI document and of course the log file that
contained captured SOAP messages.





OK, next topic is fast web services. Fast Web Services is an initiative at Sun

Current Performance Data 

Loopback Request/Response Latency

Protocol vs. Time (ms)

20 elements
Time (ms)

encoded literal


As part of fast web services effort, we measure the performance various remote
communication technologies of today. And this what we have found today.

So we have compared response time among 4 different technologies. JAX-RPC

encoding, JAX-RPC literal, RMI over IIOP and pure RMI. As expected,
RPC encoding takes longer than doc/literal since RPC encoding simply has
more tag elements. If you compare JAX-RPC literal and RMI over IIOP, the
performance difference is JAX-RPC is talking roughly twice as much time
than RMI over IIOP. Compared to RMI, it is more than 5 times slower.

Current Performance Data 

Message Size

Protocol vs. Size (bytes)

20 elements
Size (bytes)

encoded literal

In terms of message, a message that used encoded scheme is twice as big as the one
that uses literal mode, which in turn is twice the size of RMI over IIOP, which is
in turn more than twice the size of pure RMI.

Goals of Fast Web Services 

 Provide much better performance

 Standards for Fast Web Services
 Take advantage of Java™ Web
Services stack
 Fast implementation in stack
 Minimize impact to Web Service developers
 Runtime stack will hide the details
 Maintain WSDL semantics

So the goals of Fast web services is to provide much better Web services
performance. And of course we do not want to develop fast Web service as a
proprietary solution. Instead we would like to establish Fast web services
technology as a standard. We will release this fast Web services implementation
through Java Web services developer pack. And we want to achieve this while
minimizing impact to Web services developers meaning runtime stack will hide
the details so that as a developer you don't even know if you are using fast web
service underneath or not.

The Big Picture 


Unchanged Application Application

Protocol and Protocol and

Data Binding Data Binding
Can Change
Transport Transport

Fast has a goal to minimize the impact to existing specifications and thus minimize
the effect on Web Services developers and tools vendors. Fast is targeted at
developers of Web Service stacks rather than the end users of those stacks who
outnumber stack developers by a large factor.

With this goal in mind it is of paramount importance that WSDL [6], the basic
contract between a client and service, is not changed in any radical fashion.

This picture illustrates how this can be accomplished. It is possible to change the
underlying Web Services framework (consisting of a protocol, data binding and
transport layer) without affecting the application. Note that WSDL defines a
contract to all three layers depicted. To ensure no radical changes, existing
WSDL concepts such as the SOAP binding and W3C XML Schema [7], are
maintained. This ensures that the existing syntax can be interpreted differently
but consistently (see below for more details).

Technical Goals 

 Cut overhead of XML processing

 SOAP message size
 Marshaling to programmatic types
 Maximize use of APIs, tools and standards
 Support for J2ME™, J2SE™ and J2EE™
 JSR-172, Web Services for J2ME™
 End-to-end support
 Platform and programming language

So technical goals of Fast web services include cutting the overhead of XML
processing by reducing the SOAP message size and reducing the cost of
marshalling and unmarshalling.

As was mentioned, we want to provide fast web services while maximizing

the existing APIs and technologies, such as JAX* APIs and WSDL.

We want to support fast web services over all Java platforms, J2ME, J2SE,
and J2EE.

And of course, we want to make sure fast web services can be implemented as
platform and programming language independent way.

Use Cases 

 Web Services within the enterprise

 Time- and resource-sensitive systems
 Mobile phones
 High-performance computing
 Grid computing
 Scientific computing

Now higher Web services performance is desirable in most cases including for most enterprise Web
services environment. But there are cases where higher Web services performance is critical. For
example, mobile phones and satellite communications where bandwidth is a very premium resource.

The scientific grid project is an area of high-performance computing that is adopting Web Services tools
and technologies. XML-based messages in these cases can be large and do not represent the data in
the most efficient form (such as, real numbers are represented as strings).

Auto-ID [2] is an initiative to standardize the processing and management of Radio Frequency ID and
RF-ID systems. RF-ID tags, which have the size of a small coin, can be attached to every product on
supermarket shelves such that when an item is taken off the shelf, the store can order more. Just as
barcodes improved the efficiency of inventory management in the 1980s, RF-ID systems will make
further improvements in this decade, as items are individually identified and it is not necessary to
remove items from their packaging to identify them.

An Auto-ID architecture, such as Sun Microsystem's [3], can be based, in part, on Web Services. RF-ID
readers will read IDs and and send Web Service messages to servers. The readers may be small
wireless devices, so there is potential for multiple devices to send messages to a server at the same
time. The scale of Auto-ID systems and the throughput they require will be vast.

Fast can ensure that small devices may efficiently participate as Web Service clients, that bandwidth
usage from many clients sending messages is reduced, and that servers may be able to process
messages efficiently.

Technological Requirements 

 Consistent non-specific encoding technology

 Fast infoset, Fast schema and Fast SOAP
 Not specific to application
 Proven use in network communications
 Large-scale deployment
 Platform and programming language
 Existing standards
 Royalty-free and open

Technology requirements of Fast web

services. It should be consistent with non-
specific encoding technologies.

It should be something that has been proven

in large scale networking environment.

It should be platform and programming

language independent. And it is highly
desirable if we could use existing standards
that are royalty free and open.

Abstract Syntax Notation 

One (ASN.1)

 Schema language for abstract type system

 Multiple encoding rules
 Types are independent of encoding
 Royalty-free set of standards at ITU-T/ISO
 In development for nearly 20 years
 Extensively used in telecom industry
 Implementations in Java™, C and C++
programming languages

Well.. after researching through various technologies, what we decided was

ASN.1 Abstract Syntax Notation One fits our requirement.

It has been used as a schema language for abstract type system for quite a
It supports multiple encoding rules and types are independent of encoding rules.

It is royalty free international standard. And it has been proven in the market
place especially in telecom industry. There are many implementations of
ASN.1 including Java and C++ versions.

Fast Encoding and ASN.1 

 Fast infoset encoding

 ASN.1 Schema for XML infoset
 Fast schema encoding
 W3C XML Schema to ASN.1 mapping
 Fast SOAP encoding
 ASN.1 Schema for SOAP
 Packed Encoding Rules (PER)
 Most compact and CPU efficient
 Other rules could be used (e.g., DER)







 Web Services Codecamp

 Java Web Services Developer Pack Download
 Java Web Services Developer Pack Tutorial
 Sun Java System Application Server
 Sun Java System Studio 5

So these are the security schemes that are being worked on by the industry with a goal of
providing comprehensive and unified security schemes for the Web services.




 J2EE Tutorial for Sun Java Enterprise System

 Developing Amazon.com Web service client
 Sun Java Studio Web services tutorial

So these are the security schemes that are being worked on by the industry with a goal of
providing comprehensive and unified security schemes for the Web services.

Web Services Hands on Lab 

 April 21st 10:40 – 1:30

 Web Services Hands on Labs
 Carol McDonald, Chuk Munn Lee, Lin-Gang Lin,
Maneesh Sharma






Maneesh Sharma
Market Development Engineer

Sun™ Tech Days