Building Web Services in Java

Building Web Services in Java Andy Longshaw, Blue Skyline Andy Longshaw Andy Longshaw is an independent consultant, writer and educator specialising in J2EE, XML, Web-based technologies and components, particularly the design and architecture decisions required to use these technologies successfully. Andy has been explaining technology for most of the last decade as a trainer and in conference sessions. He can be contacted as andy@blueskyline.com. For more information about Andy or Blue Skyline, please see our web site at http://www.blueskyline.com or call +44 (0) 1302 759511. Introduction The world of technology moves very quickly. Vendors regularly deliver new platforms, services and tools based on new waves of technology. In the early stages of any technology revolution, the marketing always runs way ahead of the technical reality. In the case of Web Services, for example, vendors are promoting the usual panacea of possibilities. However, the reality is that many of the technologies and APIs that they are pushing at developers do not exist yet. The intention of this paper is to briefly examine the real state of Web Service development for Java programmers and designers at the time of publication (September 2001). It is anticipated that it will be of interest to Java developers and designers who wish to: Create Java-based Web Services Map between WSDL and Java Use SOAP from Java Deploy and use Java-based Web Services What are Web Services? Firstly we need to define what we mean by Web Service. Once we know that, we need a little motivation. Why should we adopt the Web Service model? Even if we decide that Web Services are good, why develop them in Java? Developer view of Web Services Essentially, Web Services take the existing application development model based around the use of components and extend it onto the Web. In the same way that many of your existing applications rely on 3rd party components, so do applications based on Web Services. However, in the case of Web Services, things are slightly different. The component functionality is hosted remotely, on a different server accessible across the Internet. The code that makes up your application will call on the functionality provided by this remote component as necessary. Blue Skyline Ltd., 2001 1

So far, so good very similar to traditional component development. However, Web Services are a mixture of the component paradigm and the Application Service Provider model of service provision. Locally installed components are more like software libraries that are instantiated and destroyed as you see fit. These remote components are actually services that have a life of their own, rather than simple extensions to your application. These services will vary from big to small scale and will also span a wide range of functionality, from coarse-grained operations (credit card processing) through to fine-grained operations (currency conversion). Some services will be seen very much as business services, while others are seen as more in the realm of infrastructure. Standards are defined or emerging in the Web Service arena. These include: Web Service Description Language (WSDL) Simple Object Access Protocol (SOAP) Universal Description, Discovery and Integration (UDDI) Electronic Business XML (ebxml) All of these will be covered as we go. Benefits of Java Web Services When looking for motivation, the first question to ask yourself is Why use Web Services?. The answer to this can be summed up as: Web Services provide a language- and platform-neutral framework for application creation and integration. Use of 3 rd party services, as with components, leads to faster development timeframes. Widespread use of Web Services will potentially ease application integration. The vendors are pushing you to use them. The next question is Why use Java?, Well, reasons include: Java is one of the principal developer languages in use today. There is lots of activity around Java Web Services, which should guarantee it being a well-supported language for Web Service development. Java-based Web Services are portable between different platforms. You like writing Java applications! Developing with Web Services If you are convinced, we will now look at how to create and deploy a Web Service in Java and some of the tools available to help you. Web Service Roles If you are interested in becoming a producer or consumer of Web Services, you will need to follow certain steps as defined below. For a Web Service provider, you will need to: Blue Skyline Ltd., 2001 2

Have a good idea for a service! Implement the service being offered (in Java naturally) Describe the service being offered Publish the description in a generally accessible place Wait for customers to find the description and then use your Web Service Sounds fairly simple, doesn t it? If you want to develop an application that uses Web Services, you will need to; Discover an interesting service Retrieve the service description Plug the description into your application Use the service This sounds even easier! The only limiting factor is that we need a convenient framework under which all of this discovery and communication can take place - otherwise it will be chaos Creating and Deploying a Web Service in Java The best way of creating a Web Service in Java will depend on your starting point: If the functionality already exists as an EJB, servlet or Java class, you will want to wrap the existing component as a Web Service. If the functionality is new, you may wish to create a new Web Service from scratch. Alternatively, even for new functionality, the best approach currently may be to write it as an EJB/servlet/class and wrap it The overall architecture for a Java-based Web Service is shown below: Blue Skyline Ltd., 2001 3

Describing a Web Service To describe a Web Service, you will create a Web Service Description Language (WSDL) document. WSDL describes not only the possible operations (including messages, parameters, return values, complex types) but also how to access them (binding information, ports, porttypes). Although they are very meaningful in terms of Web Services, WSDL documents are not very human-readable. It is possible to create a WSDL document by hand, but this is not recommended. The best thing is to use a tool to generate it automatically. This could be through automatic generation from an existing EJB, servlet or Java class (the IBM Web Service Tool Kit, or WSTK, WSDL Generator Tool wsdlgen does this), which will wrap the designated methods of the EJB, servlet or Java class. Alternatively, you could use a higher-level tool to define your business operations and generate WSDL from them. The latter mechanism could be completely Java-independent. Creating and Deploying the Web Service If your WSDL was generated from an existing class, your service is ready to deploy. Alternatively, if the WSDL is new, you need to generate a Java "skeleton" (again, the IBM WSTK Service Implementation Template Generator Tool servicegen does this). Basically, such a tool will create a Java interface from the WSDL in which the WSDL message names are mapped to Java methods. The service class then implements the interface. The Web Service must be deployed to the endpoint(s) defined in its associated WSDL. A server-side proxy must listen on the endpoint(s) and process SOAP messages that arrive. It will need to unmarshal any parameters and then route the message to the correct Java method on the target service s Java implementation. When the method has completed, it must capture any return value(s) and marshal them back. The server-side proxy will generally take the form of a servlet that acts as a SOAP router and is shared between all Web Services deployed in that servlet container. As an example, the tools servicegen and wsdlgen delivered with IBM s WSTK both create a deployment descriptor for the target environment, e.g. Apache SOAP. This contains all the routing information required to instantiate the component and invoke the method. The final piece of the puzzle is the marshalling of data between WSDL/SOAP datatypes and Java types. The mapping of Java types corresponding to XML Schema data types is simple. However, complex and custom types need specific marshalling using a Java class. Again, tool generation of these Java classes is preferable (again, provided by the IBM WSTK wsdlgen and servicegen). Typical outputs of this stage are Java serializer classes for use with the Apache client and server. Using the Web Service Although the Web Service can be used directly from SOAP, the easiest way to access it is through a Java client proxy. The client-side proxy hides the complexity of the underlying SOAP interaction. The proxy implements the same methods as server. Blue Skyline Ltd., 2001 4

Again, the best option is for a tool to generate the proxy (such as the IBM WSTK Service Proxy Generator Tool - proxygen). The tool will generate the proxy and serializer classes required. The client code can then instantiate and call the client-side proxy. Relatively little Web Service-specific code is needed, simply the address and location information and some code around any complex type conversion. As with any distributed system, you must adapt your code to handle issues such as network latency, partial failure, and the style of invocation (RPC vs. message-based). It may be that for various reasons you wish to use the Web Service directly through SOAP. You may have other, pre-existing, clients written in Java that use SOAP directly. If you wish to write a direct SOAP client you must read and understand the WSDL. Alternatively, you may have non-java clients such as.net clients using Visual Basic or C#. In this case, you can import the WSDL into Visual Studio.NET and use it to generate a proxy in the target language. This shows the true strength of Web Services. Dynamic Lookup The fully dynamic Web Services model has service information retrieved from a UDDI registry. At this point things get a bit trickier There is currently no standard Java API to access UDDI, although there are some vendor-specific solutions, e.g. IBM s UDDI4J. This is being addressed by the Java APIs for XML Registries initiative, but this is not there yet (see later). Also, there is currently no standard Java API to access WSDL, although again there are some vendor-specific solutions, e.g. IBM s WSDL4J. This is being addressed through JSR110 in the Java Community Process (see later). To use dynamic lookup, the Web Service provider must register the service in a UDDI registry. The information in a WSDL document can be split into two parts: A service interface definition, which is a reusable general description of the methods, parameters and datatypes. A service implementation definition, which defines specific endpoints at which the service can be found. In UDDI, a tmodel represents the interface definition and is registered separately from the implementation information. The tmodel structure points to the associated WSDL document. Each tmodel has a unique key by which it can be identified. To register a service, the service creator builds a UDDI businessservice structure, which contains bindingtemplates. These bindingtemplates reference the relevant tmodels and define the endpoint information for this specific service. The businessservice is stored under the businessentity for the specific organization. The raw UDDI API defines HTTP-based messages such as save_service, save_binding, and save_tmodel. The client can then retrieve the service information from the UDDI registry. Again, UDDI messages, such as find_business, find_service, find_binding, and find_tmodel can be sent to search the UDDI registry for the relevant information. These calls Blue Skyline Ltd., 2001 5

return the relevant XML structure(s) in the case of a binding, this is a bindingtemplate structure. Alternatively, if the unique key of a specific binding is known, it can be retrieved directly via the get_bindingdetail message. Once the client has retrieved the XML structure, it can be parsed and processed. All of this makes a good case for using vendor-specific APIs such as those provided by the IBM WSTK! Alternatively, leave dynamic interaction until JAXR appears. Products and Tools There are various products and tools that support Web Service creation and use. Many of them use bolt on features, usually borrowed from initiatives such as Apache, in order to provide first pass Web Service support. The two main products of interest at the time of writing (Sept 2001) are IBM s Web Service Tool Kit (WSTK) and Apache SOAP. The IBM WSTK version 2.4 provides tools and utilities that automate much of the processing of WSDL and the generation of the appropriate Java classes to act as stubs, skeletons and type converters. It also provides direct programming APIs for SOAP, UDDI (UDDI4J) and WSDL manipulation (WSDL4J). However, in many cases, the amount of code required is still large, so there is also a WSTK API to help simplify common tasks. The WSTK runtime binds to servlet container, e.g. Tomcat or WebSphere, and will invoke functionality based on EJBs, servlets or plain Java classes. IBM also has a less Java-oriented Web Service development environment in the XML and Web Services Development Environment. Apache SOAP version 2.2 supports SOAP 1.1 and SOAP Messages with attachments. It provides Java APIs for invoking SOAP RPC services and also for sending and receiving SOAP messages. It allows developers to expose Java classes as SOAP RPC servers and to create SOAP message servers in Java. The runtime, which supports HTTP and SMTP transports, plug into a servlet container, e.g. Tomcat. There are various development environments and application servers that either support (at their latest version), or are promised to support, Web Services: Forte for Java 3.0 Together Control Center 5.5 IBM Visual Age and WebSphere 4.0 WebGain Visual Cafe Borland JBuilder CapeClear s CapeStudio and CapeConnect) BEA WebLogic 6.1 IPlanet Application Server Oracle 9i and JDeveloper JCP Initiatives and the JAX Pack The Java community is driving to standardize the Java APIs and mechanisms required to build Web Services and Web Service applications. This is happening under the auspices of the Java Community Process (JCP). The core APIs: JAX-RPC, JAXM, Blue Skyline Ltd., 2001 6

JAXR, JAXP and JAXB are collectively known as the JAX Pack. The following is a brief description of the main initiatives: JAX-RPC is essentially a Java binding for RPC over SOAP. The idea is that you feed a WSDL description into compiler that then produces stubs and skeletons. The compiler will also produce Java mappings for complex types. JAX-RPC will provide APIs for invocation, marshalling, and so on, and intends to cover both forwards and reverse mappings. All in all, it looks very similar to the existing support provided in the IBM WSTK. The reason that the description is a bit vague is that at the time of writing (Sept 2001), the associated JSR101 is still in progress. There is no public specification and no early-access release available against which to test the plans. JAXM (the Java APIs for XML Messaging) provides document-centric SOAP-based messaging both synchronous and asynchronous. It also allows vendors to define profiles for specific messaging systems (ebxml is the notable one). JAXM began life as a mapping for ebxml but now is more targeted on the provision of raw SOAP messaging. At the time of writing (Sept. 2001), the JSR is close to completion - the specification is publicly available, as is an early access release which includes raw SOAP messaging capability and a sample profile for ebxml. JAXR (the Java APIs for XML Registries) provides generic XML-based registry access, this includes access to UDDI registries, ebxml Registry and Repositories and others such as the eco Framework and ISO 11179. The APIs will provide for multiple levels of registry, including business-oriented and generic functionality. Specific mappings for UDDI and ebxml Registry are defined. At the time of writing (Sept. 2001), the associated JSR093 is still in progress the specification is publicly available, but there is no early access release The JAX Pack APIs and tools will be delivered as the JSRs complete. However, it is likely that they will form the basis of Web Service support in a future version of the J2EE platform probably J2EE 1.4. In addition to the JAX Pack JSRs, two others are of note: JSR110 which defines an API for manipulating WSDL from Java and JSR109 which is trying to define a Java programming model for Web Services. The Future of Web Services As stated at the start of the paper, at the time of writing, most of the APIs and technologies used for Web Services are still works in progress. However, since they are in progress, what about the subsequent round of standards - what's next? It is certain that Web Service must evolve higher-level metadata, beyond simple interface definition. This will be needed to automate business processes between services across organizational boundaries. Initiatives such as the Web Service Flow Language (WSFL) will help to orchestrate this. There is also a pressing need to define and agree upon standard business objects in XML. To a degree, the Java standardization efforts are chasing a moving target. The World Wide Web Consortium (W3C) has yet to standardize most of the underlying technologies. Additionally, it has started a new standards initiative to create an XML Blue Skyline Ltd., 2001 7

Protocol (XMLP) to replace SOAP. On a practical note, much of the code we need to write currently should disappear under a battery of automatic code generation. Finally, there are the issues of security and context. There is currently no end-to-end security mechanism for SOAP-based messages. The forthcoming XML Digital Signature standard should help to define a mechanism for authentication and encryption for multi-stage message exchange. The propagation of context will allow information about where a user is and how they are accessing the service to be communicated. The service can then potentially alter the way it works to take this into account. Conclusion So, what can we draw from this? As stated at the start, Web Services extends the component model of development onto the Internet. Java is a good language for developing Web Services due to its popularity and the activity in the Java Web Services arena. Java also provides us with a portable implementation of a Web Service that can further aid the spread of the paradigm. Little has been mentioned here about ebxml, which is a richer model for Web-based interaction than the popular Web Service model discussed here. It already has solutions to some of the problems associated with the popular model and may yet steal a march on the WSDL/UDDI camp, especially in the B2B e-commerce space. The main area of concern is the timescale for Web Services. Many of the standards are still being solidified. Because of this, we are only just coming out of the "banging rocks together" stage as far as developing Web Services and their clients. It will take 12-18 months before Web Services really become a mainstream way of development for most developers (i.e. not the early adopters). In that time, we will learn a lot more about the scalability, security and business models associated with Web Services. References Further information on Web Services and implementing them in Java can be found at: Java Community Process, http://www.jcp.org Sun Microsystems, http://java.sun.com/j2ee/webservices/index.html IBM, http://www-106.ibm.com/developerworks/webservices/ Apache XML, http://xml.apache.org/soap/index.html Web Services Architect, http://www.webservicesarchitect.com/ Web Services Portal, http://www.webservices.org ebxml home and resources, http://www.ebxml.org Blue Skyline Ltd., 2001 8