Shoring up Web services

When your Web Services move beyond the research stage and you start considering deployment, a production-quality SOAP server becomes a necessity. Just as a Web server provides a platform for deploying Web sites and applications, SOAP servers provide the necessary infrastructure for creating reliable and scalable Web services.

Systinet Server for Java 5.0 (formerly Systinet WASP [Web Applications and Services Platform] Server) is a production-quality SOAP server with management features that will make your operations group smile. This release of Systinet Server also provides support for reliable message exchange using the WS-Addressing, WS-Policy, and WS-RM (WS-ReliableMessaging) standards.

The reliable delivery of messages is crucial if Web services are to become part of the mission-critical infrastructure that integrates applications inside and outside of the enterprise. Many business problems require that participants be assured that message exchanges will be completed. Without support for reliable messaging, the application developer becomes responsible for ensuring that messages are delivered and for avoiding duplicate message processing. This is impractical. Ad hoc, application-level solutions make it difficult and costly to extend services to other partners.

WS-Addressing gives Systinet Server a way to specify end points for SOAP services. WS-Addressing creates end point references that augment URI (Uniform Resource Identifier) information with application-specific information useful for dispatching the message. WS-Addressing’s concrete end point specifications allow Systinet Server to correlate requests with responses. This is not only necessary for reliable messaging but also a great boon to server scalability. Because a final destination can be negotiated, it allows multiple servers to go into service behind a load balancer without sacrificing reliable messaging.

I installed Systinet Server for Java on Red Hat Linux 9.0 running Java 1.4.2. Systinet’s wizard makes installation painless. Because the server is configured out of the box, it runs in stand-alone mode and is suitable for testing and small pilot projects. There are numerous configuration options for deploying a production-level server, and they are covered in detail in the 729-page manual. I ran clients against the Systinet Server from a PowerBook running Mac OS X 10.3, using the included SOAPSpy tool to view the SOAP messages traveling between client and server.

Systinet provides dozens of demos that show how to use various features of the product from both the server and client perspectives. I used these to test the server and concentrated on the WS-RM features because Systinet Server is the first product to support the standard. The support for WS-RM depends on the client, the service, or both implementing and using WS-RM’s Sequence API. Sequences are the key to reliable messaging because they are used to uniquely identity messages, find duplicates, and create a reliability context for message acknowledgement.

Systinet Server supports the reliable exchange of messages in a synchronous or asynchronous fashion, and as one-way invocations or as request-response pairs. When request-response messaging is done reliably, two reliable channels are set up to handle both directions. During my tests, using both one-way invocations and request-response, I discovered it was possible to start the client with the service offline; messages were finally delivered when the service came back up.

Reliable messaging provides a guarantee that a particular message will be delivered at most once, at least once, or exactly once, or that a number of messages will be delivered in a specific order. The Sequence API defines the methods that the delivery-guaranteeing application is required to implement. For example, a service implementing the Sequence API will include an “onPublish” method that takes an end point (defined by WS-Addressing) and creates a sequence listener. Systinet Server provides the libraries that handle the details of that negotiation.

The particular delivery guarantee that a service will provide is specified using WS-Policy directives. Policy directives, which are attached to end points, can be statically deployed with the service by simply including them in the JAR (Java Archive) file or they can be created and modified on the fly using Systinet Server’s policy run-time API.

Systinet Server has a full complement of security services. The server supports service end point authentication using HTTP Basic, HTTP Digest, WS-Security using UserName token, or Kerberos, and integrates with Netegrity SiteMinder. Access control is managed using Systinet’s Web services management console or via your enterprise LDAP or Active Directory server. Systinet Server also supports XML-Signature, XML-Encryption, and SAML.

A compelling feature of Systinet Server is its full-featured management console. The console provides facilities for configuring the server and managing the deployment and operation of individual Web service end points. The management features include the ability to enable or disable each service, run a custom test console for the service, publish the service to a UDDI server, control polymorphic serialization, manage the service’s interceptor chain, control message sizes, and enforce allowed IP addresses for clients.

One disappointment was Systinet Server’s rudimentary reporting facilities. The built-in reporting allows administrators to trace incoming and outgoing SOAP messages, monitor key performance parameters such as hits and dispatch times, and keep tabs on data throughput parameters such as message sizes and data transfer totals. These parameters are reported for each end point. This is a start, but I expected more sophistication, such as graphs showing these parameters across time and statistics for aggregated services.

Systinet Server for Java is a mature Web services deployment and management platform that provides a significant measure of control. The addition of standards-based support for reliable messaging makes Version 5.0 a slam dunk for organizations using Web services to extend mission-critical applications.