James Governor's Monkchips

Why SCA has a lot to prove: J2EE all over

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

I was at IBM’s annual analyst conference last week and the excitement levels among staff about Service Component Architecture was palpable.
 
Its such a weird industry – we get excited about the introduction of a new abstraction layer…
 
SCA is a specification designed to augment Service Data Objects (SDO).
 
IBM claims it underpins SOA as a programming model. Good luck with that.
 
I wondered at the time if IBM was so jazzed because it thinks it sees SCA as a potential chink in SAP’s armour? Wishful chinking, perhaps? Is it really likely this consortium is going to get things done:  BEA, IBM, IONA, Oracle, SAP, Siebel Systems, and Sybase? Or are we just trying to hide the turd?
 
I am sure Oracle and SAP can’t wait to provide competitors with an end run around the data closely held in their business applications.
 
I am skeptical SCA will deliver the benefits claimed, any time soon. Today I see that the WD at MWD has written the piece I would have, but with better J2EE backgrounding. So rather than repeat another analyst I simply concur: what he said.
 
Seems like Dana is pretty negative too.
 
My own linguistic bugbear- is it a service or a component? A wave or a particle? For composite apps or component business models. Doh!
 
It is certainly worth noting (reporter alert!) that Jim Marino at BEA says we will see an open source runtime for SCA. Bring it on. But then he also says the spec is far from complete.
 
So what else is new…

6 comments

  1. Hey James, thanks for the hat-tip! I actually had to rewrite that blog entry a couple of times as the first draft came out as “SCA looks like it might be another attempt to build programming model standards that lock small vendors out of a new market opportunity”. But then I thought a bit harder and realised people aren’t that sneaky 😉

    PS Still waiting to hear from you on the “debunking applistructure” release…

  2. Interesting analysis from Neil its been while since I spoke with him.

    A question that arises in my mind: if SCA forms the basis for an alternative to JCP/J2EE and an antidote for its ills – it is not clear how its development will be dramatically different.

    I’ll also be sitting at the edge of my seat chewing my nails and watching WS-* grow…

  3. Microsoft has been touting DSLs for use speficially in addressing deployment issues. This is used in specifying number of servers, how they are load balanced, failover. The DSLs are then used to automatically configure servers to meet the requirements.

    I had a quick look at the IBM spec. It’s so vague and doesn’t shed any light on use cases and why it is necessary. That’s why the world needs analysts.

  4. But you must admire our audacity to put out a new three letter acronym composed of perhaps the three most overloaded terms in the lexicon of software engineering – ‘service’, ‘component’, and ‘architecture’.

    PS – For a good SOA read check out Alan Brown, Simon Johnston, et. al.’s article on SOA in the most recent IBM Systems Journal.

  5. The reason why Soap and Web services were promoted as the best technology so far for integrating applications is because of their perceived “universality”. I do not see this unviversal nature in SCA and SDO at all.
    Why would people be happy to use a technology that is lest standard, but with the same scope as web services?
    The problem in SOA is no more the technology, it is governance, lifecycle management, versioning, good service design, etc etc…
    SCA and SDO do not bring any value for that.
    If you have those kind of problems with your SOA, I am sorry but moving to SCA, SDO is of no help.
    SCA and SDO as base technologies for a SOA: NO WAY!

  6. really solid points robin. we probably need to address a lot of other issues in SOA before we can claim a SOA programming model, especially one that currently excludes Microsoft.

Leave a Reply to james governor Cancel reply

Your email address will not be published. Required fields are marked *