WebLogic Server 7.0 contains the most advanced, performant, and standards-compliant Web service stack of any application server. With an additional download (until the JAX-RPC specification goes final - it may by the time you see this article - see http://jcp.org/jsr/detail/101.jsp) you get a Java standards-compliant Web service stack that also passes the SOAP interoperability tests. So you might ask how easy is it to use this system to call existing Web services and to build new Web services? The answer is: almost trivial.

Let's look at a concrete example to demonstrate a couple of things: (1) is it straightforward to build Web service clients and (2) the Web service stack interoperates with very complicated and intricate non-WebLogic-hosted Web services. For our Web service, let's look at the TerraServer (http://www.terraserver.com). The TerraServer is hosted by Microsoft and appears to be running the .NET runtime on the server. Our first step will be to generate the client libraries required to access the Web service from the WebLogic Server. To do so, run this Ant script:

<project name="verify" default="all" basedir="."> <target name="all" >
<clientgen
wsdl="http://terraserver.microsoft.net/TerraService.asmx?WSDL"
packageName="net.terraservice.terraserver"
clientJar="terraserver.jar" /> </target> </project>

This Ant script uses the WebLogic Web Service clientgen task to generate a client-side service factory, client-side stubs, and statically typed objects from the WSDL provided by the TerraServer's .NET service. All automatically, without user intervention. The JAR that's generated can then be placed in your EJB or WAR to let you access this service at runtime. Using the documentation that Microsoft provides for the service we can write some simple code that gets an image of the BEA San Francisco office in the lower right-hand corner (my office is on the top floor on the left side of the building):

TerraServiceSoap service = new TerraService().getTerraServiceSoap();
LonLatPt point = new LonLatPt(-122.4028244, 37.7921829); TileMeta
meta = service.GetTileMetaFromLonLatPt(point, Theme.Photo,
Scale.Scale1m); byte[] gif = service.GetTile(meta.getId(););

You can easily drop this code into a servlet to display the image or use it from a Swing application by JARring up the generated classes from the Ant script along with the classes from the webserviceclient.jar included in the lib directory of your WebLogic Server distribution. Using external Web services directly from your Java or full J2EE application has never been easier!

On the flip side, we have also added tools for deploying stateless session EJBs and arbitrary Java classes as server-side Web service components using a similar Ant task called servicegen. Not only does the task create a deployable module for your service but it also generates WSDL for your clients. This allows you to take either older EJBs that you were using for your normal J2EE applications or new EJBs/classes that you're writing for an application and automatically make then available to anyone with a proper Web service stack. In the future, not long after 7.0 ships, we'll also offer a tool that takes WSDL and generates a stubbed-out stateless session bean implementation to which you can add your business logic. This will let you take an arbitrary service specification and build an implementation without having to start from scratch. All these tools will increase your productivity, extend interoperability, and help you integrate legacy applications into your J2EE application.

Now when you combine Web services, message-driven beans, and EJBs you can see that building a simple message broker becomes a reality for the skilled J2EE programmer. So for small-scale integration systems it's now possible to build your own with off-the-shelf tools and a little hard work. For those that don't want to be distracted with the intricacies of brokering Web services, there will be a large market for products like WebLogic Integration Server in which you can build whole marketplaces from the ground up without spending your development dollars on infrastructure.

Web services are at the forefront of all new integration initiatives and because of the high interoperability between Web service stacks, they are everyone's first choice for extending legacy applications. As more and more legacy applications expose their functionality via Web services the demand for Web service integration servers will only increase. And with new applications also written to be Web services-compliant, we may not have these legacy integration problems in the future. If you build your systems now with future interoperability in mind, your applications can remain a valuable part of the software infrastructure in your enterprise.