June 13th, 2007
More heated debate on Service Component Architecture -- is it vendor lock-in?
There was an interesting and passionate thread of follow-up commentary to my post from earlier this month, “Service Component Architecture gets slapped around a bit.” Consultant David Chappell initially raised questions about the positioning of SCA as supporting SOA, but Oracle’s Dave Chappell responded that SCA has plenty to do with SOA: “The primary value proposition of SCA is about providing a common model for component assembly for building services. What’s so ‘unSOA’ about that?”
Consultant David Chappell provided some additional clarification to his remarks, noting that he is a fan of SCA, and agrees with his Oracle namesake that SCA does provide a common model for component assembly. However, that doesn’t take away from the fact that SCA does have some unSOAish characteristics, he adds. Namely, that “all of the components in this assembly must be running in the same vendor’s SCA container. Because SOA is fundamentally about cross-vendor interoperability, this requirement makes SCA much less relevant to SOA.”
Oracle David Chappell explored some of this ongoing debate in a dinner chat he had with David Chappell and other industry experts following a panel discussion on this very topic. He pointed out that “SCA is a stated direction” for Oracle Fusion Apps and Oracle Middleware. That means we’ll be using it to let you build apps that combine your business logic wit BPEL processes, business rule, BAM components, CEP et al rolled into discrete SCA composites that can be individually deployed and managed.”
IBM’s Mike Edwards, also a participant in the original SCA panel, took issue with Consultant David Chappell’s point as well, questioning where any confusion can be found when “talking about SCA and SOA in the same breath.” He asks: “Why is that? Where is the confusion, what is misleading? SCA is designed to get a handle on some of the complexities of building solutions using an SOA - it seems only too natural to talk about them in the same breath. Can someone tell us why SCA is not suited to building SOA solutions?”
Consultant David Chappell responded that the “misleading” aspect of SCA is the way vendors may be promoting it as a cross-platform architecture.
“Pretty much everybody who looks at SCA initially thinks that the distributed components in an SCA composite can be implemented using SCA containers from different vendors. This kind of assumed interoperability is what SOA is all about, and so it’s natural for people to expect this. It isn’t true, however, a fact that depending on how a vendor presents it, can easily be confusing or misleading.”
Mike observed that SCA “is a vendor-neutral specification that is as much tied to one vendor’s container as is the Java EE specification,” and asked, “how does it tie anyone to one vendor? …the existence of at least three open-source SCA runtimes today doesn’t smack of vendor lock-in.”
- Patrick Leonard of Rogue Wave Software said that he believes that “SCA is the first and only standard for true SOA development. I don’t mean Web services – we have a lot of standards for those – but a real Service Oriented Architecture:”
- “For starters, we now have a common language that gives us specific terms (like components and composites) rather that calling everything under the sun a ’service.’ Hurray! Plus it supports all of the SOA goodies: loose coupling, asynch services, and all of the existing standards that go with them.”
Patrick went on to say that “SCA provides a higher level of interoperability that includes project definition, assembly, policy and more.” Consultant David Chappell responded that he did not see this as the case, and that “all of these things are defined in a more portable way than without SCA, but portability and interoperability are quite different things. SOA is about the latter, not the former.”
- Another reader, Rtenhove, took issue with ZapThink’s Jason Bloomberg’s assertions that SCA’s value is marginal to SOA. “At its core, SCA has some valuable concepts about how to design composite applications using SOA. Bloomberg’s assertions about SCA and JBI being of “marginal” help don’t stand up to inspection. As for JBI: Bloomberg attempts to cast it as in conflict with SCA. That is nonsense. JBI is about run-time; SCA is about design-time.”
Joe McKendrick is an author and consultant with deep knowledge and insights regarding trends and developments in the technology industry. See his full profile and disclosure of his industry affiliations.
Subscribe to Service Oriented via Email alerts or RSS.
