10/08/07 :: [SCA] To Assemble or Not To Assemble, That Seems to be the Question [permalink]
Dave Chappell and I are having this discussion about SCA and interoperability. To make my position clear, I am not giving any advice to Microsoft about joining/supporting or not joining/supporting SCA.
I am simply arguing that SOA requires a web service assembly model and SCA assembly model (reduced to web services only) does the job. Dave has written an outstanding tutorial on SCA. As usual he can transform a complex subject into something that's a breeze to understand. However, if I had one thing to say about his tutorial is that it would have benefited to have a longer section on the assembly model. If you are not convinced here are my arguments:
Here are a couple of facts:
a) From both the WS-I Basic Profile 1.0 and 1.1: "R2303 A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition"
b) from the WSDL Schema 2.0 (or WSDL 1.1. for that matter):
<service name="xs:NCName"
interface="xs:QName" >
<endpoint />+
</service>
If you prefer a UML notation.
The schema or the diagram shows that “a service must have at least one end-point”.
WSDL was designed to "describe" a service from its own point of view (message types, interface and message listeners). This works in a client/server mode because the provider does not need to know anything about the consumer. However, if indeed a provider has outbound operations (notification and solicit-response or out and out-in using the 2.0 vocabulary) you are kind of stuck.
The reason I say “kind of” is because WSDL 2.0 allows you to associate multiple endpoints to different bindings which are themselves associated to specific operations of the interface. So technically, I could express that, but in the end, if I use the endpoint/bindings for that purpose I lose the “Service” concept. I say I “lose” the service concept because now, I am going to have to create a different service element for each assembly in which “my service” participates. I am not sure this was what the authors of WSDL 2.0 had in mind. No matter how you look at it, as soon as you are using peer services rather than client/server ones you need to distinguish between a service and an assembly of services, you can’t have both in one concept, at least I don’t know how to do that.
Let’s imagine a scenario where I need to assemble arbitrary services which have any number of in-out and out-in operations. How do I do that in an "interoperable" way, i.e. a .Net Service and a Java Service each need to have some information about where to send the "out-in" and "out" operations. Right?
There is only two solutions to correct this defect:
a) Remove outbound operations from WSDL (since they are forbidden by WS-I, why are they even there in 2.0?)
b) Externalize the endpoint definitions like SCA is doing it today.
In other words the <endpoint> element of WSDL need to be defined at assembly time. Service containers such as WCF already support multiple endpoints "per service" so that's fairly trivial to do. Now that the endpoints are defined at assembly time, you can of course "inject" the inbound counterpart into the outbound operation. This means that an outbound operation of a service may target two different endpoints as the service participates in two different assemblies. This is what an SCA assembly definition is doing. You just need to “distribute” an SCA definition to all the services involved in the assembly and they can configure themselves to receive messages from other participants in the assembly.
If you look on this SCA UML diagram: you can see that SCA enables a separate binding between reference and service. This means that the "service" can have access to the endpoint definition that is the target of a given outbound operation. Of course you could have a different endpoint for each operation.
This is 100% interoperability, again if your .Net service does not know anything about outbound references, well, you are going to have to do that by hand.
I regret that the SCA assembly model is convoluted with a larger component model because this give some people excuses to discard it completely and leave end-users like me to pay the price of not having this technology. The good news is that the Java community understands this problem and has lined up to solve it.