developing real world web services

��

Developing real world Web services using J2ME ™, J2SE™, J2EE™Maneesh SharmaMarket Development Engineer

[email protected]

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.

��

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

Web Service Component and Container

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.

��

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

Web Services Components

Web Service Components

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

J2EEService

J2EEClient

J2EE App Server

J2EEClient

J2EEService

J2EE App Server

Non-J2EEService

Non-J2EEClient

Service lookupThere 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 2Standard 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 Envelope

SOAP Header

SOAP Message

Primary MIME Part(text/xml)

Attachment

Attachment

SOAP Body

Header Entry

Header Entry

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

SOAP/HTTP

Port Type "fooPT"

Operation "Op1"

Operation "Op2"Service B

Port "bar"

Port "xyz"

Port ...

http://.../fooPort "foo"

Binding "fooB"

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

Service

Port

PortType Binding

Operation

Message

1..n

11

1..n

Types

1..n

Class

Interface

Package

Method Parameters

��

JAX-RPC Relationship to WSDL

Tools are used to convert between WSDL documents and sets of Java™ remote interfaces

JAX-RPC describes a Web Service as a collection of remote interfaces and methods

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:

public interface StockQuoteService extends java.rmi.Remote {

public String GetLastTradePrice (String s) throws java.rmi.RemoteException ;}

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

PORT TYPE = ABSTRACT INTERFACE OPERATION = METHOD MESSAGE = PARAMETERS AND RETURN VALUES

��

JAX-RPC Architecture Diagram

Server-side JAX-RPCRuntime System

Container

JAX-RPCService Endpoint

WSDL� Java

WSDL Document

HTTP

Client-side JAX-RPCRuntime System

SOAP

Container

Java� WSDLGenerated Code

JAX-RPC Client

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

tool

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

Implementation classesServlet-based endpoint modelOptional handler classes

Packaged application (war/ear file)

Service contractWSDL

Developing a Web Service(Bottom-up approach)

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.

21

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

22

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.

23

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

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

24

�& �� !��

Public interface Greeting extends remote { public String sayHello(String name)

throws RemoteException;}

public class GreetingBean implements SessionBean { public String sayHello(String name)

throws RemoteException { return "Hello" + name; }

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

DeploymentDescriptor

StatelessSession

Bean Class

Endpoint Interface

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

��

serviceimplementation

WSDL

JAX-RPC / JSR-109Deployment Descriptor

Serviceinterface

Web Application (WAR file)

Handlers/serializers

(optional)

Packaging ofJAX-RPC API-Based Applications

ServiceImplementation

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>>javax.xml.rpc.Stub

<<interface>>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 clientsuse Java Naming and Directory Interface (JNDI) instead to obtain aService 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.

��

� 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 slowerthan stub-based� Implementation object created and casted

Dynamic Proxy-basedInvocation Model

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 thatyou write portable, vendor-independent code. However, you need to knowthe WSDL URL at development-time and you need to run your WSDL to Javamapping tool against the WSDL document before runtime. If you do nothave this information, or if the WSDL URL is likely to change, youshould 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 ServiceFactory.newInstance();17 Service helloService =18 serviceFactory.createService (helloWsdlUrl, 19 new QName(nameSpaceUri, serviceName));20 HelloIF myProxy =

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

1

2

3

Dynamic proxyFrom a JAX-RPC Service, you can use a proxy to invoke the Webservice's operations. The proxy is a Java class implementing the SEI.A proxy is obtained with the JAX-RPC Service's getPort() method, whichtakes 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 theproxy. 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 orderto invoke the Web service's operations.In step 1, for unmanaged clients, a JAX-RPC Service is obtained fromthe JAX-RPC ServiceFactory by passing the WSDL URL as well as the

Webservice name parameter to the createService() method. For J2EEcontainer-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 theWSDL URL at development-time.Making DII calls through a Call object is programmatically morecomplex than using a stub or dynamic proxy. However, the advantage ofusing a DII Call interface is that a client can call a remoteprocedure without development-time knowledge of the WSDL URI or theWeb service operations' signatures. This makes the code easy to modifyif the Web service details change. With DII clients, runtime classesgenerated by WSDL to Java mapping tools (emitters) are not requiredlike the dynamic proxy or static stub cases. However, if you know theWeb service you want to invoke is unlikely to change, you should usedynamic 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

Service Endpoint (Port)Handler Handler

SOAP Message<Request>

SOAP Message<Response>

Handler Chain

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

��

StockQuoteService sqs = getStockQuoteService(..); // Get the instance of stub object setting username & passwordStockQuoteProvider sqp = sqs.getStockQuoteProviderPort( "<username>", "<password>");float quote = sqp.getLastTradePrice("ACME");

Example: HTTP BasicAuthentication

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

J2ME device

Configuration

Profile

JSR – 172

xml/http

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.

��

Document-driven

RPC vs. Document-driven

� Procedure call� Method signature� Marshalling� Tightly-coupled� Point to point� Synchronous� Typically within

Intranet

� Business documents� Schema� Parsing & Validating � Loosely coupled� End to end� Asynchronous � Typically over internet

RPC

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.

��

Document-driven

RPC vs. Document-driven

� Within Enterprise

� Reliable and high bandwidth

� Short running business process

� Trusted environment

� Between enterprise and enterprise

� Unpredictable bandwidth

� Long running business process

� Blind trust

RPC

When to use RPC andWhen to use Document-driven?

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

��

� 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

Document-Driven Model using JAX-RPC

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.

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

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

��Document-Style SOAP

Payload� Opaque� Schema-defined� Large� Complex

Header� Specifies message-

level services

Envelope

Header

Security

Routing

Order

Catalog

Body

HeaderBlock

BodyPayload

��

SOAP Attachments and Literals

Attachments

• Very non-restrictive– XML

javax.xml.transform.Source

– Non-XML javax.activation.DataHandler

• Parse-your-ownor use JAXB

Literals

• XML doc/structure embedded in SOAP body

• JAX-RPC parses XML, creates java objects

• Obtains service 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��

� & ��

�'��'�

��&��'��

��

��&'�

�� *

&"��

�� 2��

�� '�� *� 1 !��*

&"�� *�� "��

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, reportsand 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

FIREWALL

FIREWALL

HTTPS

HTTPS

• Web Services expose the remote methods of the Service Provider EJBs.

J2EE Application Server

SOAPProcessor

Service ProviderRemote Stateless

Session EJBWeb

Service Client Stub

WebService

Client Stub

SOAPProcessor


Session EJB

WebService

Client Stub HTTPS

• HTTPS encrypts the transmissions and gets them through the firewall.

ApplicationJava

ApplicationJava

ApplicationC++

HTTPS

��Caching Data

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

Cache

JDBC

JDBC

J2EE Application Server

JDBC

DatabaseSOAPProcessor

DataLocal Stateful Session EJB




Session EJB

WebService

Client Stub

ApplicationJava

FIREWALL

FIREWALL

HTTPS

��

��& '

��

&� �� #

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

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

“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.”

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.

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

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

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.

�� Basic Profile 1.1

� Adds support for attachments to Basic Profile 1.0

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

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.

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

��

UDDI

Configurator

RetailerWeb Page

Warehouse A

Warehouse B

Warehouse C

Manufacture A

Manufacture B

Manufacture C

Retailer

Supply Chain Management Sample Application

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

WelcomeWelcome

www.WS-I.org

SampleApp

www.vendorX.com

Configuration

www.vendorX.com

ShoppingCart

www.vendorX.com

OrderStatus

www.vendorX.com

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

Monitor

AnalyzerLog File Results

Web ServiceClient

Web Service

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.

��

Machine A

Machine AMachine A Machine B

Machine B

Machine B Machine A

Requestor

Service

Monitor Requestor

Monitor

Service

ServiceMonitor

RequestorService

Monitor

Requestor

Monitor Can Live Anywhere

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.

��

TestAssertionDocument

WSDLDocument

UDDIDocument

ConformanceReport

Analyzer

AnalyzerConfg File

MessageLog

Analyzer

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.

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

Loopback Request/Response Latency

JAX-RPC encoded

JAX-RPC literal

RMI/IIOP RMI0

2.55

7.510

12.515

17.520

22.525

Protocol vs. Time (ms)20 elements

Protocol

Tim

e (m

s)

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.

��

JAX-RPC encoded

JAX-RPC literal

RMI/IIOP RMI0

5001000150020002500300035004000450050005500

Protocol vs. Size (bytes)20 elements

Protocol

Siz

e (

byt

es)

Current Performance DataMessage Size

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.

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

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

��The Big Picture

Application

Protocol andData Binding

Transport

Application

Protocol andData Binding

Transport

Unchanged

Can Change

WSDL

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.

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

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.

��Use Cases

� Web Services within the enterprise� Time- and resource-sensitive systems

� Mobile phones� Satellites

� High-performance computing� Grid computing� Scientific computing

� Auto-ID

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.

��

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

��

� 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

Abstract Syntax Notation One (ASN.1)

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)

��

��

��

� 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

Resources

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

� java.sun.com/j2ee/1.3/docs/tutorial/doc/index.html� Developing Amazon.com Web service client

� developer.java.sun.com/developer/technicalArticles/WebServices/amazonws/

� Sun Java Studio Web services tutorial

� wwws.sun.com/software/sundev/jde/examples/index.html

Resources

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 SharmaMarket Development Engineer

[email protected]

Sun™ Tech Days

developing real world web services

Documents

webtier web services

web services endpoints

web container

web services transaction

web services orchestration

realworld web services

j2ee web service

ejb tier web services