WSI (Web services intermediaries) address the need for faster, more flexible application integration with configurable tools for creating reliable, scalable Web services networks. There are more than a dozen WSI product vendors — more if you throw in XML firewalls, which are quickly adding Web services deployment and management to their security capabilities.
I recently sat down with product managers and engineers from Actional, AmberPoint, Flamenco Networks, Infravio, and Westbridge Technology to get a preview of the new WSI products they are releasing this quarter. I discovered maturing conceptual models, more sophisticated and intuitive user interfaces, and evolutionary changes to product features.
Service virtualization is one of the staple features of WSI products. In its simplest form, service virtualization creates a proxy of the Web service, hiding implementation details from service consumers. In addition to the security benefits you get from a proxy, service virtualization has practical benefits as well. For example, it allows you to move a service from one machine to another or run it on multiple machines without affecting service consumers.
In the latest round of WSI products, service virtualization has matured and expanded to become one of the central organizing concepts. As an example, Westbridge Technology’s XMS (XML Message Server) 3.0 uses service views to create an abstraction layer for back-end services. Westbridge has already made a name for itself in the XML firewall space, and XMS is a capable WSI product in its own right.
In XMS, service administrators focus on creating service views for service consumers. Service views can be configured in one-to-many or many-to-one relationships; as examples, a single view can incorporate methods from multiple back-end services or the methods of a single back-end service can be split apart and used in different service views.
The messages destined for the methods in each view, and the responses returned, travel on a message processing pipeline that performs as many as 28 separate checks on the message. These rules incorporate steps such as authentication and authorization of consumers, message validation against a schema, signature validation, encryption, and message transformation. Each service consumer can have a custom service view if necessary, and each view can be associated with the custom-designed message processing pipeline.
The administrator can set and test properties associated with a single message on its round-trip through the pipeline. In this way, pipeline steps and properties can be combined to create sophisticated behavior. For example, an intrusion detection trap can be created by setting a custom property to true whenever a schema fails to validate so that these schema can be routed to a special “honeypot” server.
Web Self-Services
