BAH inputs on Operation Name options

BIAS participants –

I’ve pasted below some inputs received our open issue and action item related to BIAS operation names. I’m providing this as input to our discussions this afternoon.

Regards,

------------------------

Booz-Allen Feedback on BIAS Operation Name Options

This is a compilation of various feedback received from BAH SOA personnel in response to the following question:

I am working on an OASIS project developing an XML standard called BIAS. It has defined a set of operations, each of which has a name. We are debating the need to make that name visible to an entity that is handling the SOAP messages containing an operation (without looking in the message body). In other words, how (and if) the operation name should be carried in the SOAP envelope. The attached document has a quick discussion of the options identified so far.

1) David V.

What is the use case for making this information available? The use case might help to identify the best approach. That said, I can provide some information without having the complete details of your use case. If you create a forum post in the TFG forum (http://hello.bah.com/forums/index.php?board=4.0), we can share this content and the ensuing discussion with all of BAH.

If the services being created are Document/Literal style (which it should be, see WS-I Basic Profile), the root element of the SOAP body is sufficient to uniquely identify the target operation. There is no "operation overloading" in Document/Literal Web services.

The SOAPAction header is a carry-over from the days when Web services were viewed solely as RPC calls and I believe SOAP 1.2 has done away with the header altogether. It is both a security hole (see WS-I Basic Security Profile) and is not guaranteed to exist when using bindings other than HTTP. The safest bet is to set it to the empty string for all operations on your Web services. Setting the value to the empty string can be achieved by leaving its declaration out of your WSDL files. Setting the value to the empty string may have repercussions for older SOAP stacks that did not properly implement Document/Literal style services. Any modern SOAP stack should not have a problem.

There is nothing inherently wrong with using a discriminator field to identify the target operation; however, in Document/Literal style Web services, this field is not needed. If you need to reuse a single type from an existing schema within multiple operations, you need to create a wrapper element as part of your Web service. This wrapper element identifies the operation to invoke in a Document/Literal Web service. It is up to the service designers to determine if there should be many operations or a few operations and a discriminator field to determine how the few operations behave. My recommendation would be to have more operations in lieu of the discriminator field.

WS-Addressing is a great solution for this problem, it is contained in the message (therefore transport independent and easily secured using WS-Security), and provides sufficient detail to solve your problem. However, as you correctly pointed out, it does require the additional overhead of conforming to the WS-Addressing specification. Most modern SOAP stacks support WS-Addressing. If you do use WS-A, I suggest also annotating your WSDL with the WS-Addressing elements to accurately describe the service.

2) David S.

my basically uninformed opinion leads me to your option 4, but it really depends on the intended access patterns of your messages. Are there actions you can take, knowing only the type of operation? If so, you would want to bring the field up out of the body. If, however, you need other elements inside the body to do _anything_ with the message, then there's nothing wrong with leaving the operation type inside the body along with everything else.

3) Andre S.

I have used options #2 and #3 in my previous experiences. Much depended upon how much flexibility was in the servicing application. If I was consuming the service either option would be acceptable for me.

bias message