|
Comments
Did you read today's front page stories & breaking news?
SYS-CON.TV
|
Product Review Grand Central Communications' Web Services Network
Grand Central Communications' Web Services Network
By: Paul Kaiser
Mar. 27, 2003 12:00 AM
Integration efforts within an enterprise have been aided by the adoption of service-oriented architectures and common integration infrastructure. While the service-oriented architecture needs to be driven from within the organizations, a common infrastructure can come from outside. Grand Central Communications offers this via its Web Services Network. The Web Services Network Mediation The network supports messaging using both request-response and notification (one-way) patterns. Persistence, guaranteed delivery, and message expiration are available for asynchronous messages to provide the reliability required for business transactions. And both push- and pull-based delivery is supported. End-to-End Accountability Alerts can be set to generate notifications for exceptional events at the network level. Partners can even configure routing rules to produce customized event-handling mechanisms. Extensibility Security and Trust Access control to your service is available at both an implicit and explicit level. You can grant or deny access from other services as a default. And, you can explicitly grant or deny access from specific services. The organizational identity and detailed message status information form the support for nonrepudiation support in the network. Every participant knows who invoked the service, when, and what the outcome was. A Simple Start Setting up a simple routing and transformation sample was easy. With a couple of endpoint services and a routing service, you get an idea of what the network offers. Use a Grand Central sub-domain for your evaluation account. Create your services from the MyServices page of your network account. Endpoint services are associated with message queues and let you send and receive messages on the network. For now, give the endpoint services meaningful names and unique addresses and use the defaults elsewhere. Create two endpoint services: one to send messages and one to receive them. Routing services let you define rules and service invocation sequences to create a simple sequence of if-then constructs. The first rule whose logical condition evaluates as true is executed. Each rule may sequence one or more services to form a pipe and filter style process. Rule expressiveness is limited: only the sender address and message topic can be evaluated, only the equality operator is available, and you can only specify single values or leave blank to match all values. Leave the sender and topic criteria blank. Next, specify the services to which the message will be routed. Add the transformation service as the first action. Supply the address for the XML Transformation service. The Address Book feature is very convenient here. Use the defaults for message type (original) and topic (current). Specify the body: <m:transform Note that the href attribute of <input> and <output> tags uses the "cid:" prefix to refer to a message attachment and the <xsl> tag's href attribute uses the "file:" prefix to refer to the stylesheet. The stylesheet was uploaded to Grand Central's Document Manager service (www.grandcentralservices.com/docman), a simple facility for managing static files. Next we add a second action to the routing rule that sends the response from the transformation service to the receiver service created above. That completes the routing service. You can send a message to your routing service using a SOAP client, HTTP client, or Grand Central's Web messaging user interface. For brevity, I'll describe the user interface. From the MyServices page, select the Send service. Select Compose New to create a new message. Put the routing service address in the "To" field. A topic isn't required. Attach a file with the name as referenced in the <input> tag's href attribute. Send the message. If all goes well, a postmark response will indicate the new session ID and the receiver service will have a message waiting in its queue. If an error occurs, the fault response will indicate the session and call identifiers. Figures 1 and 2 show the session and call details.
Conclusion If you need the robust workflow and routing of off-the-shelf integration brokers, you may be disappointed. Later this year, Grand Central plans to provide the services and infrastructure to enable a loosely coupled, services-oriented architecture including mediation support for WS-I standards, support of advanced loosely coupled routing, and long-lived transactions. While routing services may be nested to form deep decision trees, rule selection and content access need improvement. Sending a message down multiple parallel paths has to occur outside the network and correlating the paths may prove challenging under certain configurations. But don't be discouraged. Grand Central is on the right track in support of external partner integration. Reducing interface coupling is very important to long-lived implementations. Since you have to concern only yourself with how your applications connect, the network makes it easier to scale the number of external partner integrations beyond the top tier. So take a train to the station... you might just like the ride. Company Info Evaluation Download Pricing Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
|
SYS-CON Featured Whitepapers
Most Read This Week |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||