The SCA Debate

Hartmut:

I think this point that you make: “The assembly model, which is defined by the Service Component Definition Language (SCDL), does not add to interoperability either” is, IMHO, incorrect. I was made by Dave Chappell as well.

The Web Services standard stack does not support an “interoperable” assembly mechanism. As a matter of fact, if you are adopting the WS-I Basic Profile, you are forbidden to use “outbound” operations, so your services cannot expose “references” (using SCA lingo). The only assemblies Web Services can support are of the Client/Server type (this is tenet if you build a SOA with WS only).

Further if you want your service to participate in multiple assemblies simultaneously you have to code a an assembly context management layer between your soap stack and your business logic. This layer is thin and is low value for an infrastructure software vendor like Microsoft, but it has a huge value for a customer building connected systems at the presentation, process and information layers.

SCA is two distinct pieces, IBM should probably have separated them more clearly, but Assemblies are the “last mile” of interoperability, while the programming model is purely about portability.

At the end of the day it is inconsequential that Microsoft's participate or not in SCA, because someone, if not Microsoft, will build this thin layer on top of WCF to enable the creation of SCA components running in the CLR. Incidentally, SCA is offering a distributed CLR system for any language, not just Microsoft's CLR languages. Being able to assemble Java, BPEL, php, C++ components is a powerful value proposition for a customers.

This is how I compare a SCA world with the "interoperable" world of .Net

SCA world_____________| Microsoft World
Any language support CLR____| MS languages support
Distributed CLR_____________| Local CLR
Peer-to-peer assemblies______| Binary assemblies
Homogeneous progr. model___|Homogeneous prog. model

Putting it that way, I don't see what the folks in Redmond have left to lose in adopting SCA's assembly model, unless it is an ego thing.

JJ-

I'm not sure SCA's main goal is to promote portability of programming models. Where SCA adds value, IMHO, is in a heterogeneous environment that uses different languages and technologies such as Java, C, BPEL and what have you an application developer does not have to hand-craft a composite application and can let the SCA container worry about the infrastructure details of different communication protcols, QoS issues etc. As much as MS, or for that matter, a Java vendor may not like it, heterogeneity will be a fact of life and SCA might just make things a little easier for the developers in large enterprises who do not have the luxury of sticking to a single vendor platform/technology stack. Whether the promise of simple composite application assembly will be realized or not is a separate question but positioning SCA as only tackling portability and/or interoperability perhaps misses the central point.

To quote Satadru's words: "heterogenity will be a fact of life". This also applies for programming and assembly models. Service are not pluggable components tied to a specific container. In my view this is exactly what SCA tries to accomplish. We will have portability but not interoperability. Interoperability is for heterogenous systems, portability forces components or services to adhere to the standardized specifications in order to fit in a homogenous container.
Although Jean-Jacques does not like the CORBA analogy, I agree with Stefan that SCA will require the same agreements and requirements of any vendor as CORBA did (and failed to gain).
I'm thinking of a service landscape instead of a system or assembly landscape. All management information along with policy enforcement and all other IT Management data should be included in a Service Registry. The Service Repository (included in the Registry/Repository solution) contains standardized policies, contracts, schemas and interfaces, which are associated by metadata stored within the registry. Let's simply use the standards that already exist and (more or less) solve interoperability issues. IT Management data does not have to(MUST NOT) be interoperable. Thus these data might very well be consumed and stored in a proprietary way. The basis for this data will be the standardized WSDLs, XSDs, ... Assemblies might or should be realized by composite services. The key component of a SOA is the service! We have to get rid of the traditional system/application/module/assembly metaphor.

I'm often puzzled at the perspectives I see on SCA; people sometimes project onto this emerging technology what they'd like it be rather than grasping what it really is. If you're not completely comfortable with components, composites, domains, and the rest of SCA, it might be useful to read Introducing SCA, the tutorial I wrote earlier this year.

JJ, I'm sorry, but your .NET/SCA comparison just isn't correct. There's nothing even vaguely like the CLR in SCA, for example, whether local or distributed. You might be right that some SCA vendors will provide a way to include WCF components in their composites, but it's important to understand that these extensions will be completely proprietary--the SCA specs don't define how to do this. Nor could Microsoft support SCA in this way except by building extensions that are specific to each vendor's SCA runtime--there is no SCA standard for how components interact within a domain, and a composite (today, at least) must exist within a single domain.

Satadru seems to imply that SCA will allow composites to be assembled across different technology stacks, i.e., SCA runtimes from different vendors. This is a common belief, but it's not correct. This restriction is the primary reason why I've argued that SCA doesn't have much to do with SOA: I can only create composites when all of the components are within the same vendor's domain. To me, this kind of single-vendor limitation is antithetical to SOA.

Also, Satadru correctly points out that SCA allows creating runtimes that can automatically choose bindings and make some QOS decisions. But the only reason to define a standard for this is to allow portability (or interoperability, I suppose, although SCA doesn't address this). Any vendor could build this functionality on their own if they chose, avoiding the entanglements of standards committees. What SCA adds--and it's a useful thing--is the ability to have some portability of skills and code across vendor implementations. That's why it's important.

David,
The ability to create SCA composites with components running on different SCA containers is nice but the lack of it is not as restrictive as you might think it is. It's quite unlikely that SCA vendors will only build single technology component implementations (the C&I models as per the spec) - look at Apache Tuscany 1.0 implementation - they already support Java, BPEL for C&I and they also provide an 'SCA native' extension to the runtime that supports C++ and scripting language based component implementations. So as long as I can break my application down into a *number* of composites each of which supports an appropriate stack it should not be a problem. If I have Java, C++, BPEL as well as COBOL assets and I need to construct a composite application I will need to build two composites - one with the Java, C++, BPEL components running on a la Tuscanny and the other composite containing the COBOL component (as long as I can find an SCA runtime that supports COBOL). The composites can interoperate between them via published services and references which ultimately will end up using interoperable protocols such as WS so I don't see this a s a big restriction unless I'm missing something.

You also make the point a vendor could build functionality to hide all the QoS and low-level binding/communication infrastructure details from the developer but that in my mind is the biggest danger of vendor lock-in - need evidence? This is exactly what BEA Workshop tried to do in the Java world 5 years back, albeit via proprietary constructs such as controls and it did not really go down well in the wider Java community though I strongly suspect that model did help seed some of the ideas that we see in SCA today.

You're right, Satadru: Composites can interoperate, but neither one is aware that the other is an SCA composite. The exposed interfaces of each one look just like any other Web services built using any technology. This eliminates big benefits of composites, such as dependency injection and providing a single deployment unit. This is not to say that SCA isn't useful--it certainly is--but rather that I believe a few of its proponents are overselling it in some ways.

And I think we agree on the second point. The value of a portability standard, such as SCA, is to reduce vendor lock-in.

Dave:

I think we agree on the CLR aspects of SCA. The mere fact that SCA enables multiple processes to communicate concurrently is something that is not supported by Microsoft's CLR. You can of course implement it by hand using WCF or .Net Remoting, but you do not have any "out-of-the-box" mechanism to "assemble" a complex set of concurrent processes in .Net.

Now you say:"Satadru seems to imply that SCA will allow composites to be assembled across different technology stacks, i.e., SCA runtimes from different vendors. This is a common belief, but it's not correct. This restriction is the primary reason why I've argued that SCA doesn't have much to do with SOA: I can only create composites when all of the components are within the same vendor's domain."

Again, I am not sure this is correct, there assembly definition can (and must) be deployed to all components, providing that the bindings enable interoperability between each vendor infrastructure the component implementation has enough information to configure its endpoints (both services and references). I have created SCA’s metamodel in case you want to take a look at it: www.wsper.org/sca10.png

We both had this discussion in 2004 at the Design Review meeting of WCF, SOA requires an architecture where peer services exchange messages. Today people can only build their SOA in a client server mode. Service enablement is Client/Server, even primitive SOA based business process execution schemes constrain process "steps" to "invoke" a service. Language like Erlang show the direction where things will evolve and thank god, SCA is enabling a "true" service oriented architecture, nothing else but something lie SCA is capable of delivering SOA today.

SCA and SDO are together the last mile of interoperability. SCA enables the configuration of endpoints in an interoperable way, what is impossible to do today. SDO solves another massive problem: how does a service consumer communicate the changes it has made to an XML document. Without SDO (or DataSet in .Net, but DataSet is limited to an ER model, which greatly limit its applicability in arbitrary XML Schemas), people tend to surface the update logic in the service interface which is a massive anti-pattern for SOA.

So I am sorry, Dave, but you are fighting the very necessary interoperability that would make SOA work a lot better. You are keeping everybody behind with the argument that you are making. I was the one in the SDO working group to request that we create a compatibility mode with the DataSet. I don't know what happened but this is better than nothing. I can tell you that everyone in the working group voted for this idea. People want to interoperate with Microsoft.

In an ideal world, Microsoft, would realize that customers NEED SCA and SDO and deliver what their customers need (I am living this as we speak as I participate in a project where a .Net consumer needs to communicate with a Java service and an “interoperable” dataset or sdo would be a great thing to have, I can estimate that we have to add 20% to the project because we don’t have it).
I think it is time to focus on "getting the job done" when it comes to interoperability instead of muddying the water, nobody wins “when interoperability is not good enough”. 2007 saw great progress with WSDL 2.0, WS-TX, WS-ReliableMessaging, WS-Policy 1.5, WS-BPEL 2.0 and BPEL4PEOPLE 1.0, let’s works finish the job, support SCA and SDO as an industry standard.

JJ-

Three last points, JJ:
- The SCA assembly model has nothing to do with interoperability. Composites in different domains (e.g., running on different vendor's SCA runtimes) typically communicate using standard Web services--SCA adds nothing at all here. In fact, composites communicating across domain boundaries don't even know that they're talking to another SCA-based application. All they see is an ordinary Web service, one that could just as well be implemented using WCF.
- Don't confuse SCA and SDO--they're independent technologies. Unlike SCA, SDO really does have some interoperability aspects, and it's possible that customers might benefit if Microsoft chose to support it. But neither of these technologies requires the other.
- I'm absolutely supportive of SCA. As I've often said in my blog and elsewhere, I think it has the potential to be a quite useful technology. I even invested the time to write the SCA tutorial I linked to in an earlier comment, with the goal of helping people better understand this new standard. Yet none of this changes the reality that, given its current definition, customers would gain little from Microsoft's support of SCA. I'm afraid your arguments are rooted in misunderstandings about what SCA really provides.

Dave:

I am not sure why you are using such tactics as to say " Don't confuse SCA and SDO". Shall I remind you that I was involved in the first public draft of the specifications and my text above is unambiguous? SCA and SDO are independent, serve a very different purpose, yet represent the last steps necessary for a true interoperability.

I would like to explain one more time where interoperability plays within SCA.

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"
www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-...

b) from the WSDL Schema 2.0 (or WSDL 1.1. for that matter):
<service name="xs:NCName"
interface="xs:QName" >
<endpoint />+
<service></service>

If you prefer a UML notation: www.wsper.org/wsdl20.png
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 UML diagram: www.wsper.org/sca10.png 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. Now if you want to advise Microsoft to be left behind, we leave in a free society and you are entitled to express any opinion you want.
</endpoint>

Dave:

actually even Microsoft recognize the importance of an assembly model. This is what Dino Chiesa said last June about SCA:

"Some of SCA goes beyond the basic communication plumbing, and attempts to address the larger and more complex issues surrounding the description, modeling, assembly and management of distributed systems. These are hard problems; Microsoft has been working in this area for many years, and steadily delivering infrastructure to address customer needs. For example, is shipping technology. In the .NET Framework 3.5, we'll deliver integration between WCF and WF, and the version of Visual Studio mated to .NET 3.5, Visual Studio 2008, will provide modeling tools to truly democratize the construction and deployment of conversational service-oriented applications. System Center 2007, currently shipping, enables management of distributed applications. We expect to continue to steadily deliver evolutionary innovations in these areas over time."

blogs.msdn.com/dotnetinterop/archive/2007/06/28...

JJ-