Grand Central connects Web services

Imagine a world with no Postal Service nor Federal Express. Whenever you wanted to send a document to someone, you’d have to find out how they accepted documents, find a trustworthy carrier to transport the document, and then negotiate delivery mechanisms, notification requirements, and security measures.

This is the current situation of Web services. Sure, transport is available and there are some basic standards about envelopes and how to look up an address, but there’s not much else. In fact, unanswered questions about security, reliability, trust, and coordination abound.

Even when all of these issues have been sorted out, there’s still the basic problem of how to manage multiple connections between multiple organizations, not to mention the difficulty of overcoming incompatibilities in partner and customer systems.

Fortunately, Web services networks such as the one provided by Grand Central Communications provide a solution to this problem. In much the same way that the Postal Service and Federal Express provide a trustworthy, auditable, and convenient way to deliver paper messages to other parties around the world, Web services networks can provide a trustworthy means of exchanging Web services messages. Grand Central’s network provides reliability, security, logging, and interoperability as part of every transaction.

Testing the waters

Grand Central provides two kinds of services: endpoint services and routing services. Using endpoint services, messages are routed implicitly from one endpoint to another in the Grand Central network, as long as you don’t need conditional routing or to send messages to multiple recipients.

A routing service, on the other hand, explicitly connects to endpoints and allows messages to be delivered to one or more of these endpoints based on user-defined routing rules. These rules can be made to depend on either sender or topic, which is the same as the service URI (uniform resource identifier).

Grand Central provides a developer site that has access to evaluation accounts and a significant collection of how-tos and other documentation. The place to begin is the QuickStart document, which walks you through creating a demonstration account and a basic Echo service as an endpoint on the network. This is a good way for developers to become familiar with the Web site, but anyone hoping to discover what the network can do will want to quickly move beyond this simple demonstration.

To explore the various features of the network, we created a simple temperature-conversion Web service using SOAP Lite on our server. When we were satisfied that it worked, using a direct connection from a SOAP client on our laptop, we set up a simple endpoint service on the Grand Central network to push out any SOAP message it received to the conversion service on the server.

With a few simple modifications to the client to direct calls to the Grand Central endpoint and to support authentication, we were able to access the conversion service via the Grand Central network and view the transactions in the logs. This mode of operation is known in Grand Central’s terminology as a “synchronous proxy.”

In a real-world scenario, the client and the service would probably be owned and operated by separate organizations. To imitate this, we set up a client account on the Grand Central network and created an endpoint service for this account. Our goal was to attach the new endpoint to the client, route through the Grand Central network to the endpoint for the conversion service, and then retrieve the result. To do this, we had to wind our way through the complexity of Grand Central’s concept of “from services” and “to services.”

In this example, the “from services” is the endpoint service the client calls, and the “to services” is the endpoint of our conversion service. Unconditional routing is specified in one of two ways: It can be put inside the SOAP header as part of the SOAP envelope using an XML schema proprietary to Grand Central, or it can be put into the HTTP header as part of the POST. The Grand Central developer site provides ample documentation, including code examples, to show the formats and methods necessary to complete this task.

Next we set up a routing service that would connect our two endpoints. To do this, we created a routing service that routed any message it received to the conversion endpoint. We changed the client so that the route was “to services” and spent a few hours trying to figure out why it didn’t work. With some assistance from Grand Central, we discovered that we were trying to use the routing service synchronously. Apparently, routing is available only as an asynchronous service.

Messages on Grand Central’s network can be delivered using either a “push” or a “poll” mechanism. You can think of push as a standard Web transaction in which you make a request and the response to the request is returned while you wait. This type of interaction is synchronous. Up to this point, all of our transactions had been of the push type, hence, synchronous.

A poll is asynchronous. In poll-type message delivery, there are two interactions with the Grand Central network. First, the client sends a request and receives an acknowledgement. After some unspecified period of time, the response to this request will be queued on the network. In the second interaction, the client retrieves the response, and the network notifies the sender that the message has been delivered.

Our final test was to set up a new client endpoint and modify the routing service to conditionally route to two different temperature-conversion services depending on which client endpoint was called. Using the logging on Grand Central and the logs on our server, we were able to verify that the network was routing messages to different services depending on the caller and the message topic.

In addition to routing to one of several endpoints based on the caller or the message topic, a routing service can also route to multiple endpoints or through data transformation services built into the network. Both services — endpoint and routing — can be configured to send alerts and processes exceptions on a variety of error conditions.

A piece of the puzzle

Overall the network was easy to use and the self-service feature made testing different services quick and easy. Service provisioning is made easier by features in the Web-based management tool. The availability of free developer accounts is a real plus for anyone wanting to evaluate the network.

Grand Central’s service does not come cheap, but then again, it’s not intended for casual use. The target audience consists of institutions that need reliable, auditable Web services interoperability with multiple partners.

One of the primary features of the Grand Central network is message routing. Don’t look for GXA WS-Routing-style routing just yet; that specification is still in considerable flux. Grand Central does support the GXA WS-Security standard and will add support for others as users demand them. Attachments are currently delivered in either MIME (Multipurpose Internet Mail Extensions) or DIME (Direct Internet Message Encapsulation)formats as selected by the user. The constantly changing landscape of wire-level protocols will keep Grand Central and other Web services vendors busy adding support for those that are viable and in demand.

Because the network is a platform for routing SOAP messages, it is extensible. If the network is missing a needed feature, you can simply route the message outside the network to a custom-built service that you either code yourself or purchased, and then you can route the message back to the network. This may seem counterproductive at first, but remember that this is the nature of Web services. When you subscribe to Grand Central Communications Web Services Network, you’re not paying for an end-to-end solution but a piece of the puzzle. With Web services, you’re ultimately responsible for putting the puzzle together so that it accomplishes your objective.