“SCA defines more than just a way to build services and clients. It also defines how those components can be assembled into larger modules, including specifying dependencies between them.”
This annoys me. The whole point of SOA & services is that you can define isolated, independent services. If a service has dependencies, then those dependencies should be included inside the service. Otherwise, we’re just creating a new component & packaging system akin to assemblies and jar’s, but distributed and composed of XML.
“SCA intends to let developers create service-oriented applications in a diverse group of languages. This set includes typical choices such as Java and C++, but it also includes more specialized languages such as BPEL and XSLT. WCF supports multiple languages, too, but all of them must be built on the .NET Framework’s Common Language Runtime.”
Is this really special to SCA? Isn’t this what XML promised? The idea of service interoperability reagardless of target langauge? I wouldn’t say that creating services using different langauges and connecting them using XML is special. Unless what SCA is promising is binary level interoperability, similar to what WCF delivers with other .NET based langauges. Either way, it’s a wee bit of FUD.
“SCA is meant to be implementable on top of various existing technologies, including EJB, Spring, and others. WCF is a .NET-based technology.“
Correct me if I am wrong, but Spring and EJB are built on Java, right? It seems like David isn’t comparing apples to apples here. It would be better to compare EJB to COM+ or Spring to Spring.Net ;).
“How security, transactions, and reliable messaging should be handled is described quite generally in an appendix–no specifics are given. SCA’s creators explicitly request feedback in these areas, noting that they’re complex.”
“How asynchronous and message-oriented communication should be done is also defined quite generally. Once again, the description is accompanied by a request for feedback. “
Well, it seems like the SCA members have taken care of the hard part then and left the pesky security, realibility, transactionality, and asynchronous nature of the SCA as a TODO.
“Only two bindings are defined: one for basic web services and another proprietary option for optimized SCA-to-SCA communication. Other bindings are promised, including support for WS-I profiles, the Java Message Service (JMS), and more.”
Ah, finally, the real crux of the SCA is reveled. With Java application servers becoming a commodity ( Hi JBoss! ), the other app server vendors are rushing to productize SOA using the SCA. How else would you explain why the SCA:
Doesn’t include Sun
Wasn’t created using the JCP
“A few aspects of SCA are implemented in (and apparently derived from) version 6 of IBM’s WebSphere Process Server, and the Apache-sponsored Tuscany project is getting underway to create an open source implementation of at least some parts of SCA. Still, all of the vendors backing this new spec clearly have a substantial amount of work left to do. Meeting the broad platform and language goals expressed in the initial SCA specifications won’t be simple.”
*COUGH* Buy our product if you want to do SOA *COUGH*
Also, have I mentioned that protions of WCF are already making their way to MSDN?
The nice part of all this is that, if done correctly, companies will be able to pick and chose what technologies they use to implement services.