Developing real world Web services 



using J2ME™, J2SE™, J2EE™

Maneesh Sharma
Market Development Engineer
Maneesh@sun.com

Sun™ Tech Days

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

using J2ME, J2SE, and J2EE.


Agenda 



Web Services architecture over J2EE

JAX-RPC architecture

How to develop JAX-RPC based Web
Service

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

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

messages

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

Web Service Component and 



Container

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

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
Components

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 



J2EE J2EE
Service Client
J2EE App Server J2EE App Server

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

model

WSDL to/from Java™ mapping

XML data types to/from Java™ types
mapping (serialization)

Extensible type mapping

SOAP Message Handler framework

Packaging

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
(text/xml)

Header Entry
Attachment
SOAP Body
Attachment
Body Entry

Body Entry
Attachment

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

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 and PORT TELLS THE INTERNET ADDRESS OF A WEB SERVICE

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

PORT TYPE DESCRIBES ABSTRACT INTERFACE

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


WSDL Elements


Package
Service Types
Class 1..n
Port
1 1
Interface
PortType Binding

1..n
Operation 1..n
Method Parameters
Message


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
interfaces

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"/>
</operation>
PORT TYPE = ABSTRACT INTERFACE
</portType>
OPERATION = METHOD
MESSAGE = PARAMETERS AND RETURN VALUES
public interface StockQuoteService
extends java.rmi.Remote {
public String GetLastTradePrice(String s)
throws java.rmi.RemoteException;}


JAX-RPC Architecture Diagram 



JAX-RPC JAX-RPC
Client WSDL Document Service Endpoint
Java WSDL WSDL
Java
Generated Code

Container Container

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

Runtime System Runtime System

SOAP

HTTP

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.


JAX-RPC 



 

    

# $!%


 




 
 

" !




 

 
 
 



 



  
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;
}

21

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
java.rmi.RemoteException.

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);
}

22

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
<servlet>
<servlet-name>HelloService</servlet-name>
<display-name>HelloService</display-name>
<description>Hello Servlet</description>
<servlet-
class>com.sun.xml.rpc.server.http.JAXRPCServlet</servlet-
class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>HelloService</servlet-name>
<url-pattern>/HelloService</url-pattern>
</servlet-mapping>

Generated by deployment tool

23

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 {
Session
return "Hello" + name;
} Bean Class

<session>
<ejb-name>GreetingBeen</ejb-name>
<service-endpoint>example.GreetingBeen</service-endpoint>
<ejb-class>example.GreetingBeen</ejb-class>
<session-type>Stateless</session-type> Deployment
. . . Descriptor
</session>

24


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)

Service
interface
WSDL (optional)

JAX-RPC / JSR-109
Deployment Descriptor

service
Service Handlers/
implementation
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
deployed.



 
Java Web

 

Service

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
runtime

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

com.example.StockServiceSoapBinding_Stub

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
com.example.StockQuiteProvider.


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());
stub._setProperty(
javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY,
System.getProperty("endpoint"));

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

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)
ic.lookup("java:comp/env/service/HelloService");
HelloIF hello
=(HelloIF)service.getHelloServiceProviderPort();
println(hello.sayHelloBack("Duke!"));

} catch (Exception ex) {

ex.printStackTrace();
}
}

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 %  /%


1





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=
"http://localhost:8080/ProxyHelloWorld.wsdl";
11 String nameSpaceUri = "http://proxy.org/wsdl";
12 String serviceName = "HelloWorld";
13 String portName = "HelloIFPort";
14 URL helloWsdlUrl = new URL(UrlString);



 
!  0 %  /%


1





15 ServiceFactory serviceFactory =
16
17
ServiceFactory.newInstance();
Service helloService =
1
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 }
27
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
Web
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 =

"http://localhost:8080/dynamic-jaxrpc/dynamic";
private static String qnameService = "Hello";
private static String qnamePort = "HelloIF";

private static String BODY_NAMESPACE_VALUE =

"http://dynamic.org/wsdl";
private static String ENCODING_STYLE_PROPERTY =
"javax.xml.rpc.encodingstyle.namespace.uri";
private static String NS_XSD =
"http://www.w3.org/2001/XMLSchema";
private static String URI_ENCODING =
"http://schemas.xmlsoap.org/soap/encoding/";

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

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.setTargetEndpointAddress(endpoint);

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

call.setProperty(Call.SOAPACTION_URI_PROPERTY,"");
call.setProperty(ENCODING_STYLE_PROPERTY, URI_ENCODING);
QName QNAME_TYPE_STRING = new QName(NS_XSD, "string");
call.setReturnType(QNAME_TYPE_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);

System.out.println(result);

} catch (Exception ex) {

ex.printStackTrace();
}
}
}

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





Models



 
" %  /% %  
 
 


  
  





    


 
   


 
 




 



! 

    

  

 



  " 


  




"  




 
!
  
&




  

   
% 
  

  

 
# 




 







 $
'   
"

 
" 


"
'   
"
   
"  
'   
 
 
" 





  


"  


"  


  




 

 
 
 



!



"


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
propagation

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

<Request>
Service
Handler Handler Endpoint (Port)

SOAP Message
<Response>

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(),
destroy()
}

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

Cookie-based

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

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

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.



 

 
 

Security 



HTTP basic authentication support is

required

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

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

HTTP/SSL

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

application

Add code to set standard JAX-RPC proxy Stub
properties

Username/password

Server endpoint HTTPS URL to connect to



 

 

Example: HTTP

Basic 



Authentication

StockQuoteService sqs = getStockQuoteService(..);

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

StockQuoteProvider sqp = sqs.getStockQuoteProviderPort(
"<username>",
"<password>");
float quote =
sqp.getLastTradePrice("ACME");

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
client:



 

 
 
 



J2ME and
Web Services

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

JSR-172 (J2ME Web Services) 



Parsing

J2ME Web services client

JSR – 172

Profile
xml/http
Configuration

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




clients)

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
Intranet

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

When to use
RPC vs. RPC and
Document-driven 



When to use Document-driven?

RPC Document-driven

 Within Enterprise  Between enterprise and

enterprise
 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 



JAX-RPC

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
document

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.


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
Block

Payload Routing

Opaque

Schema-defined Body

Large Order

Complex Body
Payload
Catalog


SOAP Attachments and Literals 



Attachments Literals

• Very non-restrictive • XML doc/structure

embedded in SOAP
– XML body
javax.xml.transform.Source
– 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
appservers



 

 
 
 



 $%


 

Now let's talk about document style web services.



Web

 Services & J2EE tiered


 
 
 



Architecture
&' 

& 

 
+ + &

   * %
%


 ' & 


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
perspectives

Provide notification of
updates of various mission
data


Collaborative Information Portal (CIP) 



Components

Client

Java Application

Server

Middleware (Web Services and Enterprise
JavaBeans)

Backend

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

Broadcast messages and event notification

Message-driven beans manage message archiving


Middleware Architecture 



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

HTTP
S
F
Application
Web I
SOAP Service Provider
Service R Remote Stateless
C++ HTTPS Processor
Client Stub E Session EJB
W
A
L
L

• 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
Application
W
Java JD B
A C
L
L Service Provider Data
Web SOAP
Service HTTPS Remote Stateless Local Stateful JDBC Database
Processor
Client Stub Session EJB Session EJB

C
JDB
Data
F Local Stateful
I Session EJB
R
E
W
A
L Cache
L

• 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
services.”

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
organizations

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

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 



Profiling

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

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

UDDI

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

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 



Web
Web
Service
Service
Client

Monitor

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
Monitor
Service
Requestor
Machine B
Monitor
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
monitor.

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 



Test
Assertion
Document
WSDL
Analyzer Document
Confg File
Analyzer

UDDI
Message Document
Log
Conformance
Report

XSLT

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

Current Performance Data 



Loopback Request/Response Latency

Protocol vs. Time (ms)

20 elements
25
22.5
20
17.5
Time (ms)

15
12.5
10
7.5
5
2.5
0
JAX-RPC JAX-RPC RMI/IIOP RMI
encoded literal

Protocol

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
5500
5000
4500
Size (bytes)

4000
3500
3000
2500
2000
1500
1000
500
0
JAX-RPC JAX-RPC RMI/IIOP RMI
encoded literal
Protocol

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

Interoperability

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 



WSDL

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

JAX-* APIs, WSDL

Support for J2ME™, J2SE™ and J2EE™
technologies

JSR-172, Web Services for J2ME™

End-to-end support

Platform and programming language
independent

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

Satellites

High-performance computing

Grid computing

Scientific computing

Auto-ID

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
independent

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


 

 
 
 




 




 

 
 
 

Resources


 Web Services Codecamp

 developers.sun.com/dev/edu/camps/demos/snc_web/download
.html
 Java Web Services Developer Pack Download
 java.sun.com/webservices/downloads/webservicespack.html
 Java Web Services Developer Pack Tutorial
 java.sun.com/webservices/downloads/webservicestutorial.html
 Sun Java System Application Server
 wwws.sun.com/software/products/appsrvr/home_appsrvr.html
 Sun Java System Studio 5
 wwws.sun.com/software/sundev/jde/buy/index.html

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.



 

 
 
 

Resources


 J2EE Tutorial for Sun Java Enterprise System

 java.sun.com/j2ee/1.3/docs/tutorial/doc/index.html
 Developing Amazon.com Web service client
 developer.java.sun.com/developer/technicalArticles/WebServices/amazo
nws/
 Sun Java Studio Web services tutorial
 wwws.sun.com/software/sundev/jde/examples/index.html

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

Speakers:

Carol McDonald, Chuk Munn Lee, Lin-Gang Lin,
Maneesh Sharma



 

 
 
 



Q&A



 

 
 
 



Maneesh Sharma
Market Development Engineer
Maneesh@sun.com

Sun™ Tech Days