Chappel on Microsoft and SCA

Here is one proposal as to why it would provide value for Microsoft to implement SCA: <a href="http://stage.vambenepe.com/archives/125">http://stage.vambenepe.com/archives/125</a>. It would help with intelligent management of heterogenous composite applications.

William,

I agree that it's critical to get Microsoft's management technologies to work well with managing services built on our platform.

However, I don't recall seeing a standard way in SCA to ask a service for its assembly info, so I'm not sure how SCA is solving your problem. I may be missing something - do you know?

DB

Don:

a) a technical argument
SCA fixes a vexing problem of the WS standards which had trouble to deal with outbound operations. Complex service assemblies cannot be built with something like SCA, otherwise you end up adding quite a bit of a layer between your soap stack and your code to deal with the assembly context (considering a service/component could belong to multiple assemblies simultaneously).

b) a less technical argument
simply because even if Microsoft does not join, someone will develop an SCA adapter to enable WCF-based services to participate in assemblies (not as web service references but as components). So whether Microsoft comes up with his own assembly mechanism or not (as nick seem to hint it), you might as well make sure that SCA is designed with your requirements in mind. I don't think SCA assemblies force you to adopt the SCA programming model itself.

Now if you do come with your own assembly mechanism, sure you can make the point that someone will write the Java/JEE stub. But what would be the point? There is little value in an assembly infrastructure for a vendor (this is a very thin piece of infrastructure by definition) but there is tremendous value for the customer to be able to build -heterogeneous- connected systems at the presentation, process and information layers.

JJ-

Don,
SCA doesn't define a standard way to retrieve a service's assembly info, but that's not surprising since that is typically not of use to the consumers of the service. Did you expect something like a WS-MeX dialect for SCA?
Whether it is stored in a platform-specific metadata store, in a UDDI registry or, as IBM will probably do it, in a WS-ResourceCatalog document, it shouldn't be very hard for the management tooling to retrieve it. Maybe one day there will be a shared approach to management and governance metadata but I don't see that as critical. If you compare this to all the efforts that application discovery and mapping tools (e.g. Mercury MAM) go through to paint a reasonable picture of the application, looking for SCA artifacts in a few different metadata stores is not very hard at all.