Simplicity of SCA

Last week Oracle hosted a three-day meeting of the SCA policy working group to try to accellerate progress on the current draft.
Naturally the issue of simplicity arose since ultimately people will have to learn how to use the syntax and understand its semantics. Complexity is always a potential barrier.
Someone said something like “after all, simplicity is the main reason for doing SCA in the first place.”
I am not sure about that and said so. I think that the main reason for doing SCA is to define a better way to deploy Web services onto various runtimes.
It’s possible that we’re saying the same things – certainly the Java APIs for Web services are too complicated (I have been saying this for several years), and that using the SCA metadata could simplify them.
But that perspective is somewhat limited. Enterprise software needs to be standardized, not just the Java APIs simplified, and Web services are the best potential solution to date.
Web services are not executable. Nor should they be – they are an abstraction of distributed computing concepts such as interfacing and interoperability expressed using XML – and by not tying them to any particular runtime they maintain the necessary independence to achieve standardization.
If we now want to work on the next level problem – how to consistently map the abstraction to multiple runtimes – that is where SCA comes in, or should. It is definitely a similar statement — simplicity is an important characteristic related to the potential adoption of any technology – but to me the most important thing is getting right the deployment characteristics
necessary for the success of the abstraction.
At one point during the meeting I made the joke, which comes up from time to time in these discussions (as you might imagine) that we should just get everyone to code everything in Java. Problem solved.
But of course we can’t do that. The next best solution is to ensure the abstraction layer contains the necessary functionality, and that the containers can interpret the abstractions correctly. And as simply as possible, of course.


One response to “Simplicity of SCA

  1. I agree that simplicity is good (Occam’s Razor and all that). I also agree that I didn’t think simplicity was the main reason for doing SCA. I wish I had more time to spend on the SCA effort, because I think the current specifications are not exactly simple to read and understand, let alone implement!

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s