Interesting Web Service approach

I was recently working on a client where all the integration used HTTP Web Services but were not implemented using what I think most Siebel Developers would think of as the "Best Practice".  Basically, the payloads were created using XSLT and the actual call to the Web Service was invoked using 'EAI HTTP Transport' rather than a custom WS Proxy BS created using the Tools wizard. 

The reasoning provided to me behind using XSLT to create the payload is that it was more flexible.  What do I mean by that?  Well assume an outbound interface is needed where the "Best Practice" alternative would be to use 'EAI Siebel Adapter' to query an Integration Objects , then to use 'EAI Data Transformation Engine' to transform the payload into an IO (that was initially created by consuming a WSDL) recognizable by the Web Service.  The limitation in this approach is around a couple pieces that Siebel Tools wizards have trouble with.  The first is that some modern standards compliant  WSDL definitions that use recursive data types cannot be imported at all.  The second is that the SOAP Header follows a standard that is somewhat outdated, is not configurable, and basically requires scripting to create a custom header anyway.  So the question is whether it is better to create the custom header using a scripted Filter Service, or to create the payload using XSLT.  Once you go down the path of using XSLT, you basically cant use a Proxy Service anymore (since the proxy would be adding the SOAP envelope) so 'EAI HTTP Transport' is used instead.

I can think of a number of downsides to this approach:

• Deployment Complexity increases
• XSLT files must be deployed to the File System and kept in sync across however many app servers (and failover servers) are used by EAI in the respective environments
• No WSDL is actually consumed in this approach so web service end points must be stored somewhere which will likely be different in each environment
• More Steps in the WF
• 'EAI XSLT Service'  uses UTF-16 input so it is likely Encoding will need to occur both to and from using 'Transcode Service'
• Reading the XSL File from the file system
• Mainainability
• Siebel resources that know XSLT are presumably more rare than Siebel resources familiar with more "Best Practice" approaches
• Performance
• Calls to the File System to get the XSLT file might add significant load to a high volume interface
• Data Integrity
• The integrity of the outbound message data structure is not really enforceable in Siebel. Using XSLT requires the developer to create a payload that is correct as only the external system would be able to validate it.  This is perhaps debateable because ultimately the developer will probably need to resolve this one way or the other during development.  While I personally believe it is easier to troubleshoot problems that are actually identified within Siebel due to the strict defintion of the messages maintained in Siebel, I will concede that might be personal preference.

I am curious what others think and whether developers that use this approach can defend it better than I can.  Ultimately, I think a scripted filter service is a better solution to the custom Soap Header issue, though I think this approach seems reasonable if the WSDL cannot be consumed, and modifying it is not possible.