Last week IBM hosted the SCA kickoff meeting at their executive conference center in Palisades, NY.
We discussed the importance of the assembly model and the asynchronous communication patterns, and the extent to which SCA can and should be mapped to existing runtimes such as JEE, Spring, and Celtix.
We also spent a good bit of time organizing the project and creating three working groups — one to finalize the assembly model, another to finalize the policies and bindings, and the third to finalize the client and implementation specifications. I ended up as co-chair of WG2, policies and bindings, and organized our first concall yesterday. So far, so good…
David Chappell’s (no, not that one) posted an interesting opinion piece comparing SCA with the Windows Communication Framework (WCF – formerly Indigo).
I think it’s an appropriate comparison, and a well-written piece. I also think the current SCA specs are a pretty good start, but we definitely have some work to do during the next 8-12 months.
A particular interest of ours, and not only ours, of course, is to ensure the assembly model specification progresses in coordination with the Eclipse SOA Tools Project, since the STP is relying upon the SCA assembly specification to provide critical metadata.
And now a bit of fun…
Searching for SCA on Google turns up the Society for Creative Anachronism, among many others. I used to know a guy in college who was a member of this club, and he liked to go around dressed in a helmet with horns swinging a broadsword. He complained about getting hit in the head a few too many times but otherwise he said it was a great time.
Searching for WCF turns up, among many other things, the Worshipful Company of Farriers My brother dated a farrier once, when he was living on Vashon just outside of Seattle. So I have met one, although I would not say she was particularly worshipful.
In a “Googlefight” — SCA vs WCF — SCA wins by almost tenfold.
So maybe we should add another SCA definition – Source of Creative Acronyms ;-).
Pages
Blogroll
-
Recent Posts
Archives
- February 2014
- January 2013
- December 2012
- June 2012
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005
- April 2005
- March 2005
- February 2005
- January 2005
- December 2004
- November 2004
- October 2004
- September 2004
- August 2004
- July 2004
- June 2004
- May 2004
- April 2004
- March 2004
- February 2004
Meta
Advertisements
My initial comment on what I’ve seen so far with SCA is that it contains far too much code. I’d have thought that by now we would be in a position of being able to have tools generate most of what is require, which may one day be the case, I hope!
Right now, I see all sorts of Java code being required, together with lots of XML-based files containing configuration data and so forth.
Surely, this is not going to be the “norm”?
Despite the fact that the “Googlefight” shows SCA with a ten-fold gain over WCF, comparing the effort writing code and complexity of the two tells me that SCA has a long way to go, even if it is non proprietary and all that.
It may be somewhat banal to say that time to market and speed of code completetion important– but, it is!
My hope is that SCA does not repeat the mistake of J2EE by providing wonderful APIs and interfaces which, if one understands them, provide a foundation for building great systems; if one does not, and this has often been the case, provide the foundation for building lousy systems.
John – thanks very much for the comment. I agree with you and I hope that we can keep SCA simple and avoid substituting one level of complexity for another.
Just to be clear on the Googlefight, most of the SCA hits are not related to Service Component Architecture. I didn’t mean to imply anything about the popularity of Service Component Architecture relative to Windows Communication Framework. I just found it amusing to see how many other previous uses of these acronyms are out there already!
Eric
This is great news!
Congratulations (I think) on getting the co-chair on policies and bindings. That might be the toughest of the nuts to crack.
Was there any discussion and/or direction related to the Apache Tuscany project?
How about public participation? I suppose that will have to wait until the spec is submitted to a standards body…
Hi Steve,
Thanks – I hope things go well, too.
Yes, we discussed Tuscany and some of the folks involved in SCA from IBM and BEA are also committers on Tuscany. We are also already looking at the integration of Tuscany and Celtix.
Public participation is indeed something else we discussed. A formal mechanism already exists for posting specific and detailed feedback on the specifications – for example here’s the BEA link to the formal feedback agreement:
http://dev2dev.bea.com/feedback/agreement.html?spec=sca
Because intellectual property rights are a consideration in any standarization process, the feedback agreement requires you to license your IP to the SCA authors. However, because the specifications are published using royalty free terms, any IP used in the specs will be royalty free.
However, the group also discussed the possibility of less formal participation mechanisms, and last I heard it will be more or less up to the individual working groups. Speaking for WG2 we have not yet discussed this but I think it’s a great agenda item for the next call.
The intent of publishing the specs is to get feedback, and I know I can speak for everyone on the SCA project when I say that all feedback is very important. More details will be available soon I hope about some more public discussion forums.
In the meantime though feel free to email me, or post comments to one of the authors’ SCA web pages.
Eric