Comments

# Johan Eltes said:

SCA is the first standardization effort for a component-level programming model based on dependency injection. At its core, a dependency injection framework does not provide an api. Talking about SCA as an API kind of misses the point about what SCA is about. There are API:s, but these should be considered shortcuts for users without SCA tooling or without concerns for the full value of dependency injection. The Spring framework is the de-facto-standard for dependency injection for the Java platform. JavaEE 5 is a standard, but it's dependency injection framework is intrusive (it depends on JavaEE-specific annotations). SCA - like Spring - is a zero-footprint (code-wise) DI-framework - at least on the Java platform. Unlike Spring, SCA is a standard. SCA (unlike Spring) also provides structures in terms of assembly contracts, that add enterprise-level properties like namespaces, promotion of references and services to the next level of composition etc. In my opinion, SCA is a much more mature model than Spring, when it comes supporting enterprise aspects of component library management. WCF is nothing of this. It is not a composition model based on dependency injection, which is the core value of SCA. SCA also provides bindings. From a WCF perspective, this may be viewed as competing feature. The major problem with SCA - as I see it - is that each new binding requires an extension to the standard. WCF is the opposite - a plug-in architecture for transports. From an SCA perspective, they are complementary. If SCA should standardize a single binding, it would be something like WCF. There is no standard for that in the Java world (not at the service-level). There are however open source products like Apache XCF - not as feature-rich as WCF, but on its way. But again - DI makes it less important to have something like WCF. DI abstracts even the fact that you need communication. It then becomes less important to standardize an api, since your code is not bound to any api. It's fine to use Spring remoting today, Apache XCF tomorrow and something else after that. The code remains unaffected. Going away from WCF, means changing api. Going away from SCA (i.e. to Spring) does not affect your code, nor does changing transport (in case there is communication going on in the first place).

What I think is required for contemporary development of service-oriented solutions, is a programming language with the qualities of Java and C#, a zero-footprint dependency injection framework and a service-level protocol abstraction with plug-gable transports. The later should provide glue for dependency injection frameworks. Java is a good language for SCA, SCA is an excellent (by far the most well-engineered, in my opinion) service-level dependency injection framework and its standard. SCA provides transport binding in a rigid way (not plug-gable). WCF provides the later - but only that. Although SCA is rigid, it probably covers 90% of all requirements (both SOAP-based web-services, JMS and Spring are them selves transport abstractions). A final comment on limitations of an SCA domain: A domain may be universal - and thus imposing no restrictions on the scale of the assembly model. In case an enterprise require partitioning into multiple service domains, SCA offers a concept for expressing such domains.

20 September 07 at 5:51 PM

# DotNetInterop said:

Thanks for the thoughtful comment.  

I am not sure why you are selecting this post to offer your comment on the comparison between SCA and WCF.  This post was just about OASIS' standardization efforts, and one person's opinion about it (you know what they say about opinions).

I did write yesterday (http://blogs.msdn.com/dotnetinterop/archive/2007/09/17/sca-is-an-endorsement-of-wcf.aspx) about a comparison.  And in that post, I offered that the understanding of SCA within the industry has not yet converged.  Your description is something new to me, something I had not seen before.  I take that as additional evidence for my prior point about an absence of convergence.

You seem to bring quite a bit of DI perspective to the SCA party.  Not sure SCA has ever been described in quite that way but yes I see your point.  From my perspective DI is not a good in its own right, but is an interesting potential design pattern, especially when assembling or composing distributed systems. 

You also say something provocative about DI - that DI lessens the need for WCF.  This seems like magical thinking to me.  If I have DI, then I no longer have to program the communication links?  Seriously?  "DI abstracts even the fact that you need communication."??  I think we tried this, it was called DCOM and CORBA, and it didn't work.   Abstracting away the network has proven to be a minefield repeatedly.  The fact is, the network is not invisible in many respects, and abstracting it away is dangerous and leads to many harmful effects. 

You point out, as I did (separately), that SCA does something different than WCF in its attempt to define a model for distributed systems.  I get that.   Thanks for being clear.

You also offered some comment on the SCA domain, and I think that may be a response to something I did not write here (maybe in a different post).  Beside being off the point, I don't get why your comment changes anything.  The key problem with the SCA domain is that it is a single vendor artifact. Not that it cannot be "large"  (you mentioned there are "no restrictions on the scale of the model").  It's not that the theoretical limit on a domain is too small.  My concern, although I did not articulate it in the original post here, is that the domain is a single-vendor artifact and there is no cross-domain integration, for example, between a domain hosted by vendor X's SCA container, and a domain hosted in an open source SCA container.  A domain is all managed by a single vendor's SCA "container".

20 September 07 at 10:43 PM

Leave a Comment

Comment Policy: No HTML allowed. URIs and line breaks are converted automatically. Your e–mail address will not show up on any public page.

Name (required) 

Your URL (optional)

Comments (required) 

  

Enter Code Here: Required

Remember Me?