WebSphere Service Registry and Repository V8.0 Fix Pack 2 has been released (22.214.171.124). Among the service fixes, there are new features added by the development team. Included is the subscriptions feature I previously talked about. There is now the option to copy business modeled objects, preserving their properties, classifications and relationships and allowing you to edit the copy before it is saved. You can now update document content such as WSDL or XSD content, and WSRR will correctly resolve document dependencies and re-use logical objects instead of deleting all of them. You can now author the new Web Service Mediation Policy 1.7 spec, for use with WebSphere DataPower 6 appliances, and use DataPower 6 to look up REST services registered in WSRR. Finally there is the Bulk Change Tool (BCT), which allows you to make batch changes to your WSRR data to reflect any model updates you may make to your profile. The BCT is however very technical and therefore needs IBM Support involvement before you use it.
All features will be turned off when you install WSRR 126.96.36.199, and you must explicitly configure them on to see them.
Over time I will be posting articles describing each feature in more depth, and linking them back to here.
Subscriptions in Business Space
This feature allows a user to create an email subscription to certain items from the Business Space UI, for certain activities such as deletion, update or transition. Additionally the user can choose from a list of transitions to be told about. Finally the user can see all their subscriptions and edit them. This function was originally delivered in WSRR 7.5 fix pack 3.
See my post about WSRR 188.8.131.52 for all the details.
The Object Copy feature allows you to copy a business model object from the context of a parent and the relationship to the object, pre-populate a create dialog with properties, classifications and outbound relationships from the object, then when you are done with the edits, save the copy and reattach the copy to the relationship it was copied on. Say you have a lot of custom classifications or properties you need to put onto every single endpoint you create in WSRR. This would allow you to easily add new SOAP Service Endpoint objects on the end of an SLD relationship “available endpoints”, or create new REST endpoints on a REST service, and keep all that custom metadata by copying an existing object.
See the WSRR infocenter for details of the feature.
See my post for more details on the Object Copy feature.
WSDL and XSD documents could be updated before, but now the update will use the current dependent documents of the document being updated, to resolve dependencies. The update will re-use logical objects when their WSDL or XSD objects have not changed, subject to some rules documented in the WSRR infocenter. There is a new Replace Document wizard in the Business Space UI to allow easy updating of WSDL, XSD, XML and Binary documents.
This feature allows you to update WSDLs or XSDs in the development phase, when minor changes are required. You can also now update the URL of an endpoint in a WSDL and the associated GEP object (the SOAP Service Endpoint) will update itself.
See the WSRR infocenter for more details of the feature.
More details coming soon.
Web Service Mediation Policy 1.7 & DataPower 6 REST support
DataPower 6 and WSRR V8 fix pack 2 add new capabilities for dynamic look up and policy enforcement. Now DataPower 6 can dynamically look up endpoints for REST based services that are registered in WSRR. You can register your REST services in WSRR using the WSRR REST model, and you can subscribe your DataPower appliance (virtual or real) to keep up to date with changes to the endpoints where these REST services are deployed. You can already enforce mediation policies in DataPower on WSDL based services, but now you can also enforce these same policies on REST services.
What of the new policy capabilities? In version 1.6 of the Web Service Mediation Policy (WS-MediationPolicy) spec, you could make DataPower perform policy enforcement actions when a request message was sent to it. Now in the new 1.7 spec, you can also make DataPower perform actions when the response message, or a fault message, comes back from the service being invoked. You can now get DataPower to log a message to any DataPower log, containing information such as the URL, server details and time, at any severity from informational to critical. You could in 1.6 enforce policies during certain times, and in 1.7 you can now set which time zone the time is for. You could specify a message was routed to a specific URL in the 1.6 WS-MediationPolicy spec, but now in 1.7 you can specify an XSLT stylesheet to run on the DataPower appliance, along with any number of parameters and endpoints for the stylesheet to use. This allows you to deploy a variety of XSLTs to DataPower and enable the WSRR administrator to select which one to run using a mediation policy they author in WSRR.
See the WSRR infocenter for details of the WS-MediationPolicy 1.7 support.
See a series of articles describing how to set up the integration, with a test client, and show policy enforcement. The first part is titled "Using DataPower with WSRR and REST services, Part 1: Registering, exposing, and invoking a REST service with a sample client".
With WSRR 184.108.40.206 we added some new features which will significantly enhance the WebSphere DataPower integration, and enabled some new capabilities requested by our clients. Download the fix pack from Fix Central.
Which feature of WSRR 220.127.116.11 is most interesting to you? Will you get the fix pack as soon as you can, or wait?