1 Web services for DIP LDIWG meeting C.H.Sicard 7 Jan 2003
7/01/2003 Web Services C.H.Sicard ldiwg 2 Why investigate Web services for DIP? zIt is a trend not only in the e-business or web- specific area but also in the industrial controls world: The OPC Foundation develops an OPC Data Exchange (DX) standard for Ethernet. ( ControlNet, Fieldbus Foundation, DeviceNet and PROFIBUS support the OPC working group on the DX specification.) “OPC DX (initially based on DCOM) will follow the OPC Data Access migration to the Web Service Architecture, leveraging Internet, SOAP, XML and Microsoft.NET technologies.” Nota: No implementation available yet on this basis.
7/01/2003 Web Services C.H.Sicard ldiwg 3 Functionality Universal Description, Discovery and Integration
7/01/2003 Web Services C.H.Sicard ldiwg 4 SOAP SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: y an envelope that defines a framework for describing what is in a message and how to process it, y a set of encoding rules for expressing instances of application-defined datatypes, y a convention for representing remote procedure calls and responses. It is the messaging layer for Web services and is the most important protocol in the Web services stack. Transport mechanism usually http (but not necessarily)
7/01/2003 Web Services C.H.Sicard ldiwg 5 WSDL yWeb Service Description Language yBased on abstract definition and bindings: xTypes – as defined for use in messages xMessages – the data to exchange xPort types – collection of operations xBindings – concrte protocol & data format xServices – a collection of ports yAllows automatic proxy generation
7/01/2003 Web Services C.H.Sicard ldiwg 6 Web services Toolkits IBM Web Services Bus (part of Web Services Toolkit from IBM alphaWorks) zApache Axis Sonic Software announces it has contributed its SOAP messaging capabilities to Apache Axis
7/01/2003 Web Services C.H.Sicard ldiwg 7 A Web Service toolkit: Axis Apache eXtensible Interaction System (Axis) An open source web service toolkit for Java – supercedes Apache SOAP Incredibly flexible – as will be seen when its architecture is reviewed later JAX-RPC support – moving toward full implementation – first open source JAX-RPC implementation – only free alternative to Sun’s JAX-RPC reference implementation Release 1: Oct download from Extensions planned: - asynchronous messaging extensions (JMS)
7/01/2003 Web Services C.H.Sicard ldiwg 8 Axis Features SOAP support – full support of SOAP 1.1, some support of SOAP 1.2 will eventually support all of it – some support for SOAP with Attachments Direct Internet Message Encapsulation (DIME) for binary XML EJB support – can access session bean methods as web services see org.apache.axis.providers.java.EJBProvider class SOAP message monitoring – TCP Monitor tool (tcpmon) monitors SOAP request/response messages
7/01/2003 Web Services C.H.Sicard ldiwg 9 Axis features (cont) Dynamic invocation – doesn’t use WSDL – JAX-RPC Call class invokes a web service operation must supply SOAP router URL, service namespace, operation name & parameters no compile-time parameter type checking (pass array of Objects) Web service deployment – instant deployment (JWS): copy a.java file to the “axis” web app. directory – custom deployment using a deployment descriptor uses Web Service Deployment Descriptor (WSDD) XML syntax – specific to Axis allows more control for custom type mappings,deployment without source code – standalone HTTP server ( a weak alternative to servlet-based servers such as Tomcat ) – self-contained web app. ( can add axis.jar and its helper jars to any WAR file to add web services to a web app. that will run in any servlet engine)
7/01/2003 Web Services C.H.Sicard ldiwg 10 Axis features (cont) WSDL support – Java2WSDL tool generates WSDL from Java service implementation classes – WSDL2Java tool generates client stubs for type-safe invocations, service skeletons for implementing services described by WSDL & other necessary server-side files (more on these later) – automatically generates WSDL for deployed web services clients can access by appending “?wsdl” to the web service URL which is typically (JWS) or (non-JWS)
7/01/2003 Web Services C.H.Sicard ldiwg 11 Axis features (cont’d) Type mapping –serialize Java objects to and from XML in SOAP messages – Java primitive types & registered Java Beans are handled automatically Java Beans are Java classes that follow certain method naming conventions – can customize for specified Java classes by writing and registering custom serializers and deserializers – maintained in a type mapping registry Proxy server support – through system properties http.proxyHost and http.proxyPort
7/01/2003 Web Services C.H.Sicard ldiwg 12 Example Java Web Service (JWS) Source file BasicMath.java package com.ociweb.math; public class BasicMath { public int add(int n1, int n2) { return n1 + n2; } } Steps to deploy this – create com/ociweb/math directories under axis directory in Tomcat’s webapps directory – copy BasicMath.java to that directory – rename it to BasicMath.jws Access the WSDL with – – can generate client stubs using WSDL2Java and this URL
7/01/2003 Web Services C.H.Sicard ldiwg 13 Invoking JWS services Two options – use Dynamic Invocation covered earlier – use generated client stubs covered later an example of using one follows import com.ociweb.math.*; public class BasicMathClient { public static void main(String[] args) throws java.rmi.RemoteException, javax.xml.rpc.ServiceException { BasicMathService service = new BasicMathServiceLocator(); BasicMath stub = service.getBasicMath(); System.out.println(stub.add(19, 3));
7/01/2003 Web Services C.H.Sicard ldiwg 14 Client Stubs Represent the service on the client-side – a.k.a. proxies Generated from WSDL using WSDL2Java – WSDL can be accessed locally or from a remote URL – if Java service implementation already exists, WSDL can be generated using Java2WSDL Provide type-safe invocation of web services – rather than passing parameters as an array of Objects, as is done with dynamic invocation, calls are made using an interface that specifies parameter types – rather that receiving an Object result, the interface specifies the actual result type – types are checked at compile-time
7/01/2003 Web Services C.H.Sicard ldiwg 15 Summary – Axis Pros and Cons (from a product designer!) Pros – great architecture – free and open source – well supported by IBM committers – supports JAX-RPC API – supports SOAP with Attachments API for Java (SAAJ) – large number of unit tests – regularly tested for interoperability Cons – significant changes are still being made doesn’ t yet support asynchronous message processing doesn’ t provide explicit support for SOAP intermediaries – can be implemented with custom handlers – open source some see this as a positive, while others see it as a negative
7/01/2003 Web Services C.H.Sicard ldiwg 16 Axis Server-side Architecture
7/01/2003 Web Services C.H.Sicard ldiwg 17 Usability for DIP Flexible framework Easy Java binding Can take advantage of UDDI registry, tcpmon Asynchronous messaging not yet available (not mainstream) More complex than simpler protocols Less efficient (xml encoding) High latency (w.r.to basic tcp/ip)