Developing Real World Web Services
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Developing Real World Web Services as PDF for free.
More details
- Words: 10,006
- Pages: 101
Developing real world Web services using J2ME™, J2SE™, J2EE™
Maneesh Sharma Market 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.
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 Service
J2EE Client
J2EE App Server
J2EE App Server
J2EE Client
J2EE Service
Non-J2EE Service
Non-J2EE 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 (text/xml)
Header Entry Header Entry
Attachment Attachment
SOAP Body Body Entry
Attachment
Body Entry
This picture shows SOAP message. As illustrated in the left side of the slide, a SOAP message is made of Primary mime part and zero or more attachments. The primary mime part contains SOAP envelope structure, which in turn is made of Header part and Body part. And both Header and Body parts can be made of multiple header entries and body entries respectively.
WSDL View of a Web Service
WSDL Document Service A Port "foo" http://.../foo
Binding "fooB"
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 <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location="http://example.com/stockquote"/>
PORT TYPE DESCRIBES ABSTRACT INTERFACE <portType name="StockQuotePortType"> OPERATION DESCRIBES METHOD
WSDL Elements Package Service Class
Types
1..n Port
Interface
1
1
PortType
Binding
1..n Operation Method
1..n
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"> PORT TYPE = ABSTRACT INTERFACE
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 Client Generated Code
JAX-RPC Service Endpoint
WSDL Document Java WSDL
WSDL Java
Container
Container
Client-side JAX-RPC Runtime System
Server-side JAX-RPC 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 Webtier 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>HelloServiceHelloService <description>Hello Servlet <servletclass>com.sun.xml.rpc.server.http.JAXRPCServlet 1 <servlet-mapping> <servlet-name>HelloService /HelloService 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) throws RemoteException; }
Endpoint Interface
public class GreetingBean implements SessionBean { public String sayHello(String name) Stateless throws RemoteException { Session return "Hello" + name; Bean Class } <session> <ejb-name>GreetingBeen <service-endpoint>example.GreetingBeen <ejb-class>example.GreetingBeen <session-type>Stateless Deployment . . . Descriptor
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 implementation Implementation
Handlers/ 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
<> 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 02 03 04 05 06 07 08 09 10 11 12 13 14
package proxy; import java.net.URL; import javax.xml.rpc.Service; import javax.xml.rpc.JAXRPCException; import javax.xml.namespace.QName; import javax.xml.rpc.ServiceFactory; public class HelloClient { public static void main(String[] args) { try { String UrlString= "http://localhost:8080/ProxyHelloWorld.wsdl"; String nameSpaceUri = "http://proxy.org/wsdl"; String serviceName = "HelloWorld"; String portName = "HelloIFPort"; URL helloWsdlUrl = new URL(UrlString);
! 0 % /% 1
15 16 17 18 19 20 21 22 23 24 25 26 27 28
ServiceFactory serviceFactory = ServiceFactory.newInstance(); Service helloService = serviceFactory.createService(helloWsdlUrl, new QName(nameSpaceUri, serviceName)); HelloIF myProxy = (HelloIF) helloService.getPort( new QName(nameSpaceUri, portName), proxy.HelloIF.class); System.out.println(myProxy.sayHello("Duke")); } catch (Exception ex) { ex.printStackTrace(); } } }
1 2
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 import import import import import
javax.xml.rpc.Call; javax.xml.rpc.Service; javax.xml.rpc.JAXRPCException; javax.xml.namespace.QName; javax.xml.rpc.ServiceFactory; 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 Handler
Handler
Service Endpoint (Port)
SOAP Message
This picture shows how multiple handlers can form handler chain. Here SOAP request message is intercepted by handler # 1. Handler #1 peforms some handler logic and then pass the request to the handerl #2, which performs its own handler logic and then it passes the request to the service endpoint. And response message then goes through the handler chain in reserve order. Again, this chain of handlers is configured at the time of deployment and at the client side, it can be configured during runtime.
Example SOAP Message Handler
package com.example; public class MySOAPMessageHandler implements javax.xml.rpc.handler.Handler { public MySOAPMessageHandler() { ... } public boolean handleRequest(MessageContext context, HandlerChain chain){ try { SOAPMessageContext smc = (SOAPMessageContext)context; SOAPMessage msg = smc.getMessage(); SOAPPart sp = msg.getSOAPPart(); SOAPEnvelope se = sp.getEnvelope(); SOAPHeader sh = se.getHeader(); // Process one or more header blocks // ... // Next step based on the processing model for this handler } catch(Exception ex) { // throw exception } } // Other methods: handleResponse(), handleFault(), init(), 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 Configuration J2ME device
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.
RPC vs. Document-driven
Document-driven
RPC
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
Web services can be implemented in two different models - RPC model and documentdriven 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 and RPC vs. Document-driven When to use Document-driven?
Document-driven
RPC
Within Enterprise
Reliable and high bandwidth Short running business process Trusted environment
Between enterprise and enterprise Unpredictable bandwidth Long running business process 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 JAXRPC? 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
Specifies messagelevel services
Envelope Header Security
Payload
Opaque
Schema-defined
Large
Complex
Header Block
Routing
Body Order
Catalog
Body Payload
SOAP Attachments and Literals
Attachments • Very non-restrictive – XML javax.xml.transform.Source
– Non-XML javax.activation.DataHandler
• Parse-your-own or 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.
Services Web & J2EE tiered Architecture
1 ' * 1 ! *
*
* % %
&" *
& ' "
&"
2
' '
&
&'
+ &
+
Synchronous Web services are architected using a JAXRPC 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
Application Java
•
Web Service Client Stub
Application Java
Web Service Client Stub
Application C++
Web Service Client Stub
Web Services expose the remote methods of the Service Provider EJBs.
F I R E W HTTPS A L L
J2EE Application Server
SOAP Processor
HTTPS
HTTP S F I R HTTPS E W A L L
SOAP Processor
•
Service Provider Remote Stateless Session EJB
Service Provider Remote Stateless Session EJB
HTTPS encrypts the transmissions and gets them through the firewall.
Caching Data
Application Java Web Service Client Stub
F I R E W A L L HTTPS
J2EE Application Server Data Local Stateful Session EJB
JD B C SOAP Processor
Service Provider
Data
Remote Stateless Session EJB
Local Stateful Session EJB
JDBC
JDB
F I R E W A L L
•
Database
C
Data Local Stateful Session EJB
Cache
The Cache Registry keeps track of which Data EJBs are in memory.
& '
& # Now let's talk about WS-I and Web services interoperability.
WS-I Is
“An open industry effort chartered to promote Web Services interoperability across platforms, applications, and programming languages. The organization brings together a diverse community of Web services leaders to respond to customer needs by providing guidance, recommended practices, and supporting resources for developing interoperable Web 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
Retailer Web Page
Configurator
Warehouse A
Manufacture A
Retailer
Warehouse B
Manufacture B
Warehouse C
Manufacture C
As a way of making sure actual implementations from different vendors interoperate, WSI 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 Service Client
Web Service
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 B
Machine A
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 Document
Analyzer Confg File Analyzer
UDDI Document
Message 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)
Time (ms)
20 elements
25 22.5 20 17.5 15 12.5 10 7.5 5 2.5 0 JAX-RPC encoded
JAX-RPC literal
RMI/IIOP
RMI
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)
Size (bytes)
20 elements
5500 5000 4500 4000 3500 3000 2500 2000 1500 1000 500 0 JAX-RPC encoded
JAX-RPC literal Protocol
RMI/IIOP
RMI
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
Can Change
Application
Application
Protocol and Data Binding
Protocol and Data Binding
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 nonspecific 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 [email protected]
Sun™ Tech Days
Maneesh Sharma Market 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.
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 Service
J2EE Client
J2EE App Server
J2EE App Server
J2EE Client
J2EE Service
Non-J2EE Service
Non-J2EE 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 (text/xml)
Header Entry Header Entry
Attachment Attachment
SOAP Body Body Entry
Attachment
Body Entry
This picture shows SOAP message. As illustrated in the left side of the slide, a SOAP message is made of Primary mime part and zero or more attachments. The primary mime part contains SOAP envelope structure, which in turn is made of Header part and Body part. And both Header and Body parts can be made of multiple header entries and body entries respectively.
WSDL View of a Web Service
WSDL Document Service A Port "foo" http://.../foo
Binding "fooB"
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 <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location="http://example.com/stockquote"/>
PORT TYPE DESCRIBES ABSTRACT INTERFACE <portType name="StockQuotePortType"> OPERATION DESCRIBES METHOD
WSDL Elements Package Service Class
Types
1..n Port
Interface
1
1
PortType
Binding
1..n Operation Method
1..n
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 = 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 Client Generated Code
JAX-RPC Service Endpoint
WSDL Document Java WSDL
WSDL Java
Container
Container
Client-side JAX-RPC Runtime System
Server-side JAX-RPC 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 Webtier 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
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) throws RemoteException; }
Endpoint Interface
public class GreetingBean implements SessionBean { public String sayHello(String name) Stateless throws RemoteException { Session return "Hello" + name; Bean Class } <session> <ejb-name>GreetingBeen <service-endpoint>example.GreetingBeen <ejb-class>example.GreetingBeen <session-type>Stateless Deployment . . . Descriptor
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 implementation Implementation
Handlers/ 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
<
<
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 02 03 04 05 06 07 08 09 10 11 12 13 14
package proxy; import java.net.URL; import javax.xml.rpc.Service; import javax.xml.rpc.JAXRPCException; import javax.xml.namespace.QName; import javax.xml.rpc.ServiceFactory; public class HelloClient { public static void main(String[] args) { try { String UrlString= "http://localhost:8080/ProxyHelloWorld.wsdl"; String nameSpaceUri = "http://proxy.org/wsdl"; String serviceName = "HelloWorld"; String portName = "HelloIFPort"; URL helloWsdlUrl = new URL(UrlString);
! 0 % /% 1
15 16 17 18 19 20 21 22 23 24 25 26 27 28
ServiceFactory serviceFactory = ServiceFactory.newInstance(); Service helloService = serviceFactory.createService(helloWsdlUrl, new QName(nameSpaceUri, serviceName)); HelloIF myProxy = (HelloIF) helloService.getPort( new QName(nameSpaceUri, portName), proxy.HelloIF.class); System.out.println(myProxy.sayHello("Duke")); } catch (Exception ex) { ex.printStackTrace(); } } }
1 2
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 import import import import import
javax.xml.rpc.Call; javax.xml.rpc.Service; javax.xml.rpc.JAXRPCException; javax.xml.namespace.QName; javax.xml.rpc.ServiceFactory; 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 Handler
Handler
Service Endpoint (Port)
SOAP Message
This picture shows how multiple handlers can form handler chain. Here SOAP request message is intercepted by handler # 1. Handler #1 peforms some handler logic and then pass the request to the handerl #2, which performs its own handler logic and then it passes the request to the service endpoint. And response message then goes through the handler chain in reserve order. Again, this chain of handlers is configured at the time of deployment and at the client side, it can be configured during runtime.
Example SOAP Message Handler
package com.example; public class MySOAPMessageHandler implements javax.xml.rpc.handler.Handler { public MySOAPMessageHandler() { ... } public boolean handleRequest(MessageContext context, HandlerChain chain){ try { SOAPMessageContext smc = (SOAPMessageContext)context; SOAPMessage msg = smc.getMessage(); SOAPPart sp = msg.getSOAPPart(); SOAPEnvelope se = sp.getEnvelope(); SOAPHeader sh = se.getHeader(); // Process one or more header blocks // ... // Next step based on the processing model for this handler } catch(Exception ex) { // throw exception } } // Other methods: handleResponse(), handleFault(), init(), 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 Configuration J2ME device
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.
RPC vs. Document-driven
Document-driven
RPC
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
Web services can be implemented in two different models - RPC model and documentdriven 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 and RPC vs. Document-driven When to use Document-driven?
Document-driven
RPC
Within Enterprise
Reliable and high bandwidth Short running business process Trusted environment
Between enterprise and enterprise Unpredictable bandwidth Long running business process 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 JAXRPC? 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
Specifies messagelevel services
Envelope Header Security
Payload
Opaque
Schema-defined
Large
Complex
Header Block
Routing
Body Order
Catalog
Body Payload
SOAP Attachments and Literals
Attachments • Very non-restrictive – XML javax.xml.transform.Source
– Non-XML javax.activation.DataHandler
• Parse-your-own or 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.
Services Web & J2EE tiered Architecture
1 ' * 1 ! *
*
* % %
&" *
& ' "
&"
2
' '
&
&'
+ &
+
Synchronous Web services are architected using a JAXRPC 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
Application Java
•
Web Service Client Stub
Application Java
Web Service Client Stub
Application C++
Web Service Client Stub
Web Services expose the remote methods of the Service Provider EJBs.
F I R E W HTTPS A L L
J2EE Application Server
SOAP Processor
HTTPS
HTTP S F I R HTTPS E W A L L
SOAP Processor
•
Service Provider Remote Stateless Session EJB
Service Provider Remote Stateless Session EJB
HTTPS encrypts the transmissions and gets them through the firewall.
Caching Data
Application Java Web Service Client Stub
F I R E W A L L HTTPS
J2EE Application Server Data Local Stateful Session EJB
JD B C SOAP Processor
Service Provider
Data
Remote Stateless Session EJB
Local Stateful Session EJB
JDBC
JDB
F I R E W A L L
•
Database
C
Data Local Stateful Session EJB
Cache
The Cache Registry keeps track of which Data EJBs are in memory.
& '
& # Now let's talk about WS-I and Web services interoperability.
WS-I Is
“An open industry effort chartered to promote Web Services interoperability across platforms, applications, and programming languages. The organization brings together a diverse community of Web services leaders to respond to customer needs by providing guidance, recommended practices, and supporting resources for developing interoperable Web 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
Retailer Web Page
Configurator
Warehouse A
Manufacture A
Retailer
Warehouse B
Manufacture B
Warehouse C
Manufacture C
As a way of making sure actual implementations from different vendors interoperate, WSI 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 Service Client
Web Service
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 B
Machine A
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 Document
Analyzer Confg File Analyzer
UDDI Document
Message 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)
Time (ms)
20 elements
25 22.5 20 17.5 15 12.5 10 7.5 5 2.5 0 JAX-RPC encoded
JAX-RPC literal
RMI/IIOP
RMI
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)
Size (bytes)
20 elements
5500 5000 4500 4000 3500 3000 2500 2000 1500 1000 500 0 JAX-RPC encoded
JAX-RPC literal Protocol
RMI/IIOP
RMI
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
Can Change
Application
Application
Protocol and Data Binding
Protocol and Data Binding
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 nonspecific 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 [email protected]
Sun™ Tech Days
Related Documents
Developing Real World Web Services
November 2019 11
Real World
April 2020 21
Web Services
November 2019 38
Web Services
November 2019 48
Web Services
November 2019 43