WebSphere ESB (and Process Server) Version 7.0 is generally available as of today which, amongst other things, means that I’m free to blog at will about the product content. As is traditional, I’ll start with an overview of what’s new in this release of the product (and the associated WebSphere Integration Developer tooling). Over the coming weeks I hope to cover each of these areas in more detail.
Service Federation Management: I’ve touched on this previously in my post on the product announcement as it is the area on which my efforts have been focussed for this release. The basic thesis is that many enterprises consist of a number of disconnected domains each with their own services. These domains could correspond to lines of business, geographical boundaries, or exist as the result of mergers and aquisitions. What service federation management aims to do is to simplify the sharing of services from one domain to another. A Business Space based console is shipped with the WebSphere Service Registry and Repository Feature Pack. This console allows the definition of multiple domains, each of which has its own registry instance. Existing services in those domains can then be grouped and shared from one domain to another via the console. In addition, a domain may contain one or more connectivity providers (WebSphere Message Broker or WebSphere ESB). When a service group is shared from one domain to another, a proxy can be created in either the provider or consumer domain or both.
Patterns/Proxy Gateway: The existing pattern support in WebSphere Integration Developer has been radically updated. In addition, a new service gateway pattern has been added: proxy gateway. The existing dynamic proxy pattern requires the integration developer to determine what the target service for any given invocation is. The proxy gateway pattern allows back-end services to be defined in an internal registry via a new Business Space widget. Each service is provided with an unique virtual service name that can then be appended to the export endpoint address to identify the target service. A new endpoint lookup primitive is utilized in the flow to retrieve the target service meta-data from the registry. Consequently, a proxy gateway scenario can now be implemented out of the box.
Data Transformation: There have been considerable enhancements to the XML map support. XPath functions can now be accessed directly. “Smart” data type support allows direct mapping between compatible types e.g. date to dateTime conversion. User-defined lookups can be implemented with support for static relationship, CSV, and property file, lookups out of the box. If/else if/else constructs are also now supported. Refactoring support has been added. To name but a few enhancements…
Policy-Driven Mediation: The mediation policy Business Space widget that shipped with the V6.2 Feature Pack is now part of the base product. It is also now possible to attach policies to individual services, service endpoints and operations, in addition to the existing module level policies.
Subflows: Support for subflows (the area I worked on in V6.2) has also be enhanced. It is possible to set the types of the in/out nodes of a subflow to be weakly typed thereby promoting greater reuse. It is also possible to extract part of an existing flow in to a new subflow (although it is then necessary to define the wirings to the in/out nodes explicitly).
Mediation Primitives: No release of the product would be complete without a set of new mediation primitives:
- Message Validator – validates that the message matches the schema
- Trace – prints a trace message to the server log
- SLA Check – ensures that the service requestor has an SLA defined in WSRR
- Flow Order – allows the order of invocation to be defined where a mediation flow branches
- UDDI Endpoint Lookup – enables a service lookup based on business name, service name or find qualifiers
- Gateway Endpoint Lookup – as mentioned previously, allows service endpoint information to be retrieved based on a virtual service name
Mediation Flow Editor: When creating a new mediation flow component implementation you’ll immediately notice a difference to the editor. The operation connections view has gone and, when creating the flow, you are now presented with a set of template options permitting either a one-to-one or one-to-many mapping, or for you just to start with a blank canvas and add callout nodes to references as and when they’re needed. This takes a bit of getting used to for seasoned users but should be more intuitive for the beginner. Then, when editing the flow itself, the request/respones tabs have moved to the top of the editor alongside a new breadcrumb navigation, the combination of which makes it much easier to see which flow you’re currently working on. Another great usability improvement is the ability to click on any terminal in the flow and see the structure of the service message object at that point.
Quality of Service: Event sequencing, previously only supported in WebSphere Process Server, is now available in WebSphere ESB too. There is also a new store and forward qualifier. This can be applied to asynchronous invocations and indicates that, when a given exception occurs (e.g. ServiceUnavailableException), the request messages should be requeued ready to be forwarded at a later point.
Bindings Enhancements: The web service bindings have had support for referenced attachments added. For a JAX-WS binding, it is also possible to modify the response endpoint dynamically within the mediation flow enabling responses to be redirected to a different client application. For the messaging bindings, there is now failed event manager support for all of the binding types. With the move to be based upon WAS V7, the WebSphere MQ related bindings can now also make use of the WebSphere MQ JCA resource adapter. For a JMS import where the response is being sent to a topic, it is also now possible to modify the topic dynamically during the mediation flow. The EJB binding can now be specified on an export as well as an import with support for both EJB 2.1 and 3.0, local and remote interfaces.
WebSphere Service Registry and Repository Integration: In addition to the new SLA check primitive already mentioned above, the existing endpoint lookup primitive has been enhanced. It is now possible to specify the required version dynamically. Lookup for JMS, HTTP and MQ binding types is also now supported. For situations where it is necessary to access WSRR from a custom Java primitive, for example to perform a custom query or to retreive other objects types, it is now possible to use the same client SPI used by the endpoint lookup primitive. This enables custom code to use the same WSRR definitions and caching mechanism used by the provided primitive.
Congrats on both your new deliveries. I hope the latter won’t give as many sleepless nights as the first one is bound to do!
Thanks Mike. I can always try the product development equivalent of sleeping in the spare room…
[…] and WebSphere Integration Developer – v7.0. David has already done a good job of describing the new features, but we can combine two of them – untyped subflows and the Trace primitive – to create […]