SCA = Scary Component Architecture?

15 Sep

Only just catching up with SCA/SDO as part of some work with a current client and have to say that there seems to be a great deal of confusion around these essentially useful specs.  First of all read the threads over at Joe McKendrick’s blog where a conversation raged for a while over the utility of SCA but then also came across this blog post by Dana Gardner over at FASTForward complaining about Microsoft’s unwillingness to play ball.  This latter post confused me deeply.  Dana (and others that he references) seem disturbed by the fact that Microsoft are not involved in this effort and that this represents a blow to ‘SOA interoperability’ and an unwillingness from Microsoft to be open.  This seems like a strange statement to me as from what I can glean from the specifications for SCA and SDO – and from great resources such as those provided by Dave Chappell – these proposals seem to be more about how you create components that sit within a particular realisation environment – realistically Java ones given the spread of vendors involved – and they seem to say nothing about interoperability per se.  Interoperability across realisation technologies (even across specific containers in fact) is left – very sensibly in my view – to existing web service standards.  So far so good in my view as the Java community have badly needed some support in simplifying the creation of lighter weight services of the sort needed in a federated world, since Java EE’s component roots are based on a previous generation of architectural model, IMHO, and as a result it has become way too complex.  Suggestions that Microsoft are not ‘open’ however on the basis of the fact that they only provide support for interoperability standards seems perverse to me.  Whether you are using SCA to compose applications that will realise services within a specific Java vendor’s environment, using WCF within the Microsoft world – or indeed ignoring all of these and resorting to simpler, more dynamic environments such as Ruby – surely having a range of programming models and platforms competing to realise services most efficiently is a healthier model than trying to force them to create service realisations in the same way?

The suggestion that we would have a common programming model that transcends implementation language, however, (as seems to be implied by Dana’s post and indeed others that I’ve read) seems a bit oxymoronic to me as surely our existing XML standards (of whichever flavour you prefer) take care of the multi-language aspect of the problem space, leaving composition as the main issue to be addressed (since BPEL only partially addresses this space).  I’m all for interoperability as a way of enabling competition in the provision of implementations but less ecstatic about the idea of trying to arrive at a converged programming model with a confusing mix of service and implementation metadata.  To be honest I feel that trying to mix the interoperability and implementation spaces by pushing a converged realisation model onto vendors introduces unnecessary complexity and so would not be a good approach to solving the issues around service composition.  Trying to talk SCA up as a way of enabling interoperability across implementation technologies (which again I have to stress is not something I believe the spec authors are doing) is a shame as it confuses an area around which we absolutely need more research and guidance, namely specific ways of modelling composite services – whether UML-based via the OMGs recent call for a services profile, as part of the STP project within Eclipse or via DSLs such as those supported by Microsoft. In each case, however, I feel that these should be at a level of abstraction above the individual technologies being composed since surfacing this information makes consumption a much more complex proposition by putting the onus on the consumer to take responsibility for integration rather than forcing the provider to expose their services using existing standards.

I guess I’m also influenced by the fact that I lived through the CORBA period where we tried to implement a standard programming model and – realistically – failed.  When I compare the subsequent success that the industry has had by concentrating on simplicity and interoperability suggestions of conformity of approach across realisation  technologies feels – to me at least – like a backward step out of touch with the current zeitgeist; currently we’re increasingly looking at simple, open, web based technologies that are ‘good enough’ and rail against the complexity of WS-*.  Such pragmatism has unleashed a wave of innovation from companies both large and small and anything that could introduce constraints and confusion to this model by trying to develop an uber-model of implementation feels to me like a bad idea. One of the great drivers of recent success has been federation – moving responsibility for service enablement to the endpoints (i.e. providers) to enable consistent and simplified consumption of these by consumers.  Trying to deliver a cross-language rather than web based composition model feels to me very much like the old school EAI approach that we have only just recovered from, moving information about endpoints back into the consumer space and increasing the complexity of the composition space.  it all makes me feel vaguely like I’ve returned to the mid-90s (not something you want to do if you’re Welsh as it was probably one of the worst periods in the checkered history of our rugby team).  At the end of the day I would rather see standardisation at the ‘what’ level (i.e. interoperability) than at the ‘how’ level (i.e. programming model) since it feels to me that this is the sweet spot for having your cake and eating it – an ability to work simply and consistently with anyone whilst allowing them maximum scope for innovation on your behalf. 

Whilst being uncomfortable with the idea that SCA represents some kind of uber-programming model, however, I do absolutely recognise the need to simplify service realisation in the Java space and therefore am heartily on side with it’s core aims.  I guess I’m more interested in the next level of composition, however – i.e. composition across standards-based services – rather than just on improvements in the way that one or more particular technology stacks supports developers in the creation of services that execute within their environment.

Advertisements

3 Responses to “SCA = Scary Component Architecture?”

  1. Ron September 17, 2007 at 8:48 pm #

    Every few years, there is an attempt (usually by IBM) to create the One True Programming Model. SCA is the first such attempt of the 21st century, but it won’t be the last, if past history is anything to judge by. SCA will fail, because the world neither needs nor wants such a beast. Why do I want to use the same component model for different programming languages? For closely-coupled POJOs and composite service orchestration languages like BPEL? And hasn’t the world invested enough in existing component models (e.g., EJB)? Are we practitioners begging for NEW Java component models?

    Finally, lets put a persistent SCA lie to rest — it isn’t about inter-language interoperability. You can’t just wire a Java service interface to a C++ (or other language) service reference, and expect it all to work. Sorry folks, the coolest, most compelling novelty that seems to be part of the SCA model is simply a lie.

    Scary indeed.

  2. Ray September 18, 2007 at 4:15 am #

    Very intresting blog!
    I’ve noticed SCA/SDO years ago and It made me recall San Francisco. Ideal design, Idle result. But we should admit that it’s a kind of innovation. About WCF and SCA/SDO’s compration, refer to http://www.cnblogs.com/msdpe/default.html?page=2
    (It’s written in Chinese:))

  3. Jean-Jacques Dubray September 26, 2007 at 1:06 pm #

    Guys:

    SCA can tie in a reference to any web service, so whether Microsoft would like it or not, they indeed interop with SCA composites. There is little value for them to play at the programming model level.

    At the end of the day WCF was designed in a client/server mode (this was one of the hidden tenets of SOA). SCA opens up a peer-to-peer model where services can be “assembled”, not just composed in a BPEL fashion. As many have pointed out, including David Chappell, Eric Newcomer,… the value of SCA is not so much in its programming model (which is helpful for the Java world) but rather in its assembly model. How can you do SOA without an assembly mechanism that can assemble more than two services at a time? I don’t think there has ever been something like this available before SCA.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: