New feature coming for freebxml Reg/Rep (Omar): SOAP Interceptors!

There is a new feature being reviewed and tested for the open-source freebxml 
Registry/Repository implementation (Omar):  SOAP Interceptors!  

The purpose of this email is to solicit feedback from the user community as 
to what you think of this impending feature (note: it's not available 
yet...not even in CVS), what kinds of uses you think it might be good for and 
the like.

So make your opinion heard!


Introduction:

The SOAP Interceptor Plugin allows registry users to selectively intercept 
SOAP requests and to modify these requests (and related responses) before the 
registry processes them.   

Target Use Cases:

The principle use case for this feature is enable Omar to be able to 
transparently handle domain-specific vocabularies for requests, and hide the 
ebXML Reg/Rep request/response plumbing/schema complexities.

For example, you could provide HL7 or UBL vocabulary support so that the 
registry can receive an HL7 or UBL-based request and know how to translate 
that into native ebXML Registry/Repository syntax and execute it, basically 
providing a nice way to map a domain request onto the RIM.

A more advanced use case, leveraging SOAPInterceptors' ability to create 
dynamic RegistryItems from the original request, is automatic code generation 
of RIM mapping XSLT's. For example, a SOAPInterceptor can transform the 
request input into a new mapping XSLT and store that XSLT transform in the 
Repository as a RepositoryItem, for later use.

Another use case would be to provide a transparent upgrade path when Omar or 
ebXML Reg/Rep specfications change the schemas and/or syntax of requests that 
the registry accepts. A SOAP Interceptor could be provided that would 
translate older syntax (ie. Omar 3.0 or ebXML Specification 3.) requests into 
the new formats (ie Omar 4.0 or future ebXML Reg/Rep specifications). A good 
example would be if the XML-based query syntax was replaced with XQuery 
capability. Older XML-based syntax could be intercepted and transformed into 
XQuery format, and thus lessen the conversion burden on existing users, and 
provide them with a more palatable and easer upgrade path, requiring little 
or no rework of their existing applications.


SOAP Interceptor Framework:

This feature provides a complete and flexible SOAP Request/Response 
interceptor framework (SOAPInterceptorManager) implementation, along with an 
off-the-shelf XSLT Interceptor (XSLTSOAPInterceptor) which can do dynamic 
transformations on incoming and outgoing SOAP requests. Other interceptor 
implementations can be added as well, and we expect to provide a Pipelined 
XSLT Interceptor not too far down the road.

The provided XSLTSOAPInterceptor implementation allows you to use a XSLT 
transform to alter incoming requests and outgoing responses. The XSLT 
interceptor implementation can also create new "attachments" as part of the 
transformation process, so it's possible to process a request in a domain-
specific XML vocabulary that can also create RegistryItems. This feature is 
intended for XML-based artefacts like XSLT's, WSDL's, etc, that need to be 
dynamically generated.

The definitions and configuration of the interceptors are stored in the 
registry (as ExtrinsicObjects of a specific type. If you change an 
interceptor definition, then the SOAPInterceptorManager detects this and 
reloads itself, thus providing real-time reconfiguration capability.


Examples:

Omar comes with demos which show how the SOAPInterceptorManager and 
XSLTSOAPInterceptor can be used. Comprehensive unit tests are also included.

More details on this impending feature can be found here:

http://ebxmlrr.sourceforge.net/wiki/index.php/Dev/omar/design/serverPlugin/SOA
PInterceptor

Please feel free to pass on any thoughts you might have about this new 
feature.

 
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com