Doron Sherman

Subscribe to Doron Sherman: eMailAlertsEmail Alerts
Get Doron Sherman: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal

J2EE Journal: Article

Developing Web Services with WebSphere Studio

Developing Web Services with WebSphere Studio

So you've heard all about how great Web services are and how they are revolutionizing the way distributed systems are being developed. You've read all about how this new set of standards is changing the Enterprise Application Integration (EAI) space and how it's finally making interoperability possible. You've even heard that it's possible to make calls on code written in C# and deployed using ASP.NET and have read an article or two about SOAP, WSDL, and UDDI. It's time to take the next step.

This month I thought it fitting to cater to those of you ready to take the plunge and try your hand at developing a Web service or a Web service client. Incidentally, if you still haven't done all the recommended reading, don't sweat it - you really don't have to know too much when using WebSphere Studio. Also, this article will try to bring you up to speed, but just a bit though - wouldn't want to bore the folks who've already read it all.

If you're reading this magazine, chances are you're using the IBM WebSphere family of products. This means you're using the WebSphere Application Server as your deployment environment and some combination of WebSphere Studio and/or VisualAge for Java as your development environment. Web services are fairly new on the technology map and thus also on the WebSphere product roadmap. Web services were first supported by the Web Services Toolkit, which was introduced on alphaWorks. More importantly, as of version 4, Web services are directly supported by the WebSphere Application Server (WAS) as well as the WebSphere Studio development tools. This two-part article explains how to create and use Web services using the new WebSphere Studio product line, specifically using WebSphere Studio Application Developer (WSAD).

This month I'll focus on the use of WSAD to develop and publish a Web service. You'll see how to use the Web services wizard to wrap an existing Java method as a Web service and expose the metadata required for invoking the service. You'll then see how to use another tool - the UDDI Explorer - to publish your service on a public registry so others can find and use it. Next month I'll focus on building a client that invokes the Web service and on running a sample test application.

The WebSphere Studio Product Family
Starting with version 4, a new set of development tools has been introduced as part of the WebSphere Studio product family. IBM now offers two new tools - WebSphere Studio Site Developer (WSSD) and WebSphere Studio Application Developer (WSAD). Those of you who have been using WebSphere Studio in one of its previous incarnations or who have been using VisualAge for Java will be pleasantly surprised. Both of these new tools are much better in terms of the developer's experience and in terms of the tools available to save time.

WSSD targets Web developers who are focused more on the Web application than on underlying server code. WSAD is a more complete environment that supports Web developers but provides more focus on J2EE developers. Both environments allow you to develop Java code and both tools support the development of Web services in a similar way, but if you are a hardcore developer, chances are that you will be using WSAD. In any case, both tools share a common development metaphor and both support the development of Web services in a similar way. The examples in this article use WSAD, but they are also relevant to those of you who prefer using WSSD (which is overall a simpler tool to use).

Application Developer (as well as Site Developer) is based on the concept of a developer role and implements a set of perspectives. A perspective is an organization of the workbench that focuses on a developer role and presents the "best-practice" layout of the tools most often used in that developer role. For example, the Web perspective focuses on the set of tools for editing JSPs, scripts, servlets, etc. The Server perspective includes the server configuration pane for the WebSphere test environment, the test environment console, and a set of tools used for configuring the test environment. You can open many perspectives and easily switch between them when you go through the code-test-debug-package cycle.

You use WSAD for all development tasks. Whether you mostly develop JSP, EJB, core Java code, or Web services, WSAD is the tool you consistently use. One of the implications is that VisualAge for Java is being phased out and WSAD is replacing it. Don't be sad - WSAD is superior in every aspect and you'll find it very easy to use. IBM has done a nice job in packaging all these tools together in a way that makes it powerful and usable at the same time. (Just for the record - I don't work for IBM and [unfortunately for me] I'm not getting paid by IBM to say these things.)

Web Services and WSAD
Without going into any of the (very interesting) details, a Web service is a method that is deployed on an application server and invoked over the Web. Web services are usually used by other applications and systems and are becoming the preferred way to integrate and interoperate in environments that involve decoupled, distributed applications.

What makes a method deployed on an application server a Web ser-vice is not the "what" but the "how." A Web service invocation is done using the Simple Object Access Protocol (SOAP). SOAP is an XML-based protocol that packages the arguments needed to invoke the service along with the invocation details, routing details, and more. The SOAP message usually travels over HTTP, but other underlying protocols may also be used. SOAP is a de facto standard. It is backed by the entire software industry, including IBM and Microsoft. This is what makes Web services so special and so powerful. It means that there is finally an agreed-upon way to communicate between different platforms; let's just hope it stays this way and that no one thinks of "extending" it (after having "embraced" it).

There are two more standards involved with Web services - the Web Services Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI). WSDL defines how to describe a Web service. After all, if you develop a ser-vice for others to use you need to be able to tell them how to invoke the service. WSDL documents the metadata with which a client application learns how to invoke the ser-vice and describes things such as where the service is deployed, what arguments to pass in, and what the return value will look like. Once you have this document you need to publish your service to a UDDI registry using the UDDI APIs available from such registries. Sometime later, client applications make UDDI calls to search for a service based on some criteria, discover your service, get the WSDL description, and start using your service.

SOAP, WSDL, and the UDDI APIs are standards and are therefore well-documented. They are all based on XML and it's therefore possible for a human to read and write such documents. You can (theoretically) write SOAP messages and WSDL descriptions using your favorite text editor.

If you've had much experience with XML you already know that XML documents tend to be verbose. Because SOAP, WSDL, and UDDI offer comprehensive support for distributed invocations, these XML documents tend to quite quickly become complex and difficult to write. Therefore, you should not be writing these XML documents yourself. Instead, you should be using tools - specifically WSAD.

WSAD hides the complexity of the mechanics of Web services behind a set of tools and wizards. You can do all your Web services development quickly and efficiently without writing a single line of XML. You can also publish Web services on a registry using a WSAD tool. It's time to move on and see some of the magic.

Developing the Web Service
Assume you're building a Web service that uses advanced optimization algorithms to create efficient driving patterns. People who need to visit a set of locations during a work day access your service and tell you where they need to go. You in turn have a smart routing and optimization engine and access to historical traffic patterns with which you can suggest an optimal sequence that the person should visit in order to minimize driving time. Your service can be used by applications used by delivery drivers, service technicians, claims adjustors, and more.

Assume that you already have the Java code that performs this optimization (maybe you already implemented this for your company and now want to create a new revenue stream by selling the service to other companies). In order to simplify things, assume you have a class called WorkOrderSequencer that has a method with the following signature:

public int[]
getWorkOrderSequenceForEmployee(long[]
lats, long[] longs)

 

As input you receive two arrays with the latitude and longitude coordinates for the places that the employee needs to visit. Your reply is an array with the sequence order. For example, if you are passed 10 locations, you may return an array of the form {4,6,2,3,1,8,9,7,0,5} meaning that the person should first visit the location with the fourth latitude/longitude, then the location with the sixth latitude/longitude, and so on.

Having the method implemented is just the beginning - what you really want to do is develop the Web service - the wrapper through which your method can be called from another system. You use WSAD's Web services wizard in order to do that. The wizard guides you through a set of simple steps and at the end "wraps" your method with a Web service and generates all the files needed for you to deploy the Web service (along with the implementing code) on a WebSphere Application Server. Obviously, the WAS instance needs to be enabled for Web services - as is WAS version 4.

As an example, Figure 1 shows the wizard panel in which you specify which class to wrap, Figure 2 shows the wizard panel in which you specify where the service is located and where the metadata and WSDL files should be stored, and Figure 3 shows the wizard panel in which you select which methods to wrap as Web ser-vices and what type of XML encoding should be used for marshaling arguments.

When you complete filling in all your preferences, the wizard goes to work. It generates all the needed metadata files for the SOAP invocation to be handled correctly. It also generates all that is required for making a Web service invocation - but that's part of next month's column.

Let's look at the metadata that the tool generates on your behalf, i.e., all the hard work it saves you. The first thing that the wizard generates is an XML Schema Definition (XSD). The XSD describes the types used within the Web service. Listing 1 shows the XSD generated based on the method's signature. It defines complex types for an array of int and an array of long as extensions to the SOAP array type.

Next is the service description defined by the WorkOrderSequencer-Service.wsdl shown in Listing 2 (some of the details are omitted for the sake of brevity). This WSDL file defines the location of the service using a SOAP address that's embedded in a port definition. The SOAP address - the most important element - specifies how client applications invoke the service. The address always points to a fixed servlet, the rpcrouter. This is part of the Web services infrastructure packaged within WAS version 4. This servlet receives requests and maps the ser-vice request to the implementing class - the class and method you are wrapping as a Web service.

The service WSDL file imports the binding WSDL file. The binding WSDL (shown in Listing 3) includes a definition for the remote interface, a definition for all possible messages (both requests and responses, because SOAP is inherently asynchronous), and the operation definitions along with the encoding properties. Clearly, I've glossed over the gory details because they could fill tens of pages. That's the beauty of WSAD - you don't need to know any gory details in order to develop Web services!

Publishing the Service
Once you finish developing a Web service you usually proceed to test it and debug it. Then you package your application as an EAR (that has a WAR) and install it on your WAS instance. Once you complete all these steps you have a Web service deployed on the Web. The only problem is that no one knows about it.

That's what registries are for. Specifically, UDDI registries allow you to publish your Web services for other applications to discover and use. They allow you to define a business (with a set of descriptive parameters) and the Web services provided by this business.

There are two kinds of UDDI registries - public and private registries. Private registries are registries that you implement yourself within an organizational boundary. For example, you might want to implement an interdepartmental registry as part of your enterprise architecture. Such registries aren't normally open to the general public. Public registries, on the other hand, are open for anyone to use. As an example, IBM implements a public registry called the IBM UDDI Business Test Registry. You can register as a user at https://www-3.ibm.com/services/uddi/ testregistry/protect/registry.html, after which you can publish and discover services using this public registry.

UDDI registries are accessed using a set of Web services (what else?). In order to publish a service on a UDDI registry, you issue a SOAP message using one of the UDDI APIs. Once more, WSAD saves you the hassle by providing a tool - the UDDI Explorer. This tool allows you to define all of the properties and then creates the SOAP messages on your behalf.

The UDDI Explorer is used to publish your business and Web services and also used to discover services - but you'll have to wait until next month to learn about that. When publishing your business you specify its name, phone number, e-mail address, and other contact information. You also classify your business using the United Nations Standard Products and Services Classification (UNSPSC), the North American Industrial Classification System (NAICS), or a geographic classification (e.g., country and state). These classification schemes help someone looking for a certain type of business to find you - similar to the way yellow pages are used. For example, Figure 4 shows some possible UNSPC categories you could choose from in order to classify your business.

After publishing your business, go ahead and publish the Web service. You can again classify the service using categories from any of the mentioned classification schemes. In addition to that you specify the URL for the WSDL file describing your Web service. A service consumer using the UDDI registry will find your service while doing a search for one of the categories and then will use the WSDL to learn where the service is deployed and how to invoke it.

Summary
Web services are among the newest, greatest (and certainly most hyped) technologies to hit the e-business landscape recently. It isn't surprising therefore that the latest versions of both WAS and WebSphere Studio provide support for Web services. This month's article described the support provided by WebSphere Studio Application Developer for developing and publishing Web services. This is only half of the story - WSAD also supports discovering Web services and building client applications that make use of these services, which is the topic of next month's installment.

More Stories By Ron Ben-Natan

Ron Ben-Natan is Chief Technology Officer at ViryaNet Inc. Prior to that he worked for companies such as Intel, AT&T Bell Laboratories, Merrill Lynch and as a consultant at J.P. Morgan. He has a Ph.D. in Computer Science in the field of distributed computing and has been architecting and developing distributed applications for over 15 years. His hobby is writing about how technology is used to solve real problems and he has authored numerous books including “IBM WebSphere Application Server: The Complete Reference” published by Osborne/McGraw. He can be reached at

More Stories By Doron Sherman

Doron Sherman is the CTO of Collaxa, Inc., a Web Service Orchestration Server vendor and a BEA Partner located in Redwood Shores, California. He has been involved with Java since its early days and pioneered application server technology while being a founder and chief scientist at NetDynamics.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.