David Chappell

  • September 2020
  • November 2017
  • April 2017
  • October 2016
  • March 2016
  • February 2016
  • August 2015
  • April 2015
  • December 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • July 2012
  • June 2012
  • May 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 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
  • January 2004
  • December 2003

Opinari

Get the Feed! Subscribe

Introducing SCA  
# Monday, July 16, 2007
 
Service Component Architecture (SCA) isn't an especially simple technology. It's also hard to figure out just by reading the specs. To help make clear what SCA is, I've written a white paper that introduces the topic, available here.

My original goal for this paper was to create a straight tutorial that all of SCA's creators would agree was accurate. This turned out to be impossible. Different vendors have different perspectives on how SCA should be presented and even on which parts of the technology are important. Accordingly, while I've done my best to be accurate and objective, I'm certain that there will be some disagreement with how I've described or positioned a few things. Still, my hope is that there's value in an overview of the topic from somebody with no particular vendor ax to grind.

And one more thing: Although everything I produce reflects my take on a topic, I get paid for most of the papers I write. That's not the case here. I've been interested in SCA since it first went public in late 2005, yet I don't think this technology has gotten the attention it deserves. Maybe providing a place for people to start understanding it can help change that.


16 comments :: Post a Comment

 


Comments:

Excellent piece of work that helped me really understand what SCA is all about and what the stakes are.
As an Enterprise Architect, I can unfortunately not afford to ingest each and every detailled specification in the world, but I need to have a good level of understanding of the main ones.
And, although I've heard about SCA since its beginning, I never really managed to understand exactly what it is. This is the first paper which really gave me the depth and breadth of understanding that I was long waiting for.

Again excellent Job.
 

David,

This is the best introductory paper I have seen on SCA and I will be sure to recommend it. Thanks for offering such a fair and balanced analysis devoid of marketing hype.

Jim Marino
BEA Systems and SCA Specification Participant
 

David,

Overall a great paper, but I have to disagree where you say:

For instance, the @Scope attribute with the conversational option can only be used with protocols that can pass session information, such as a SOAP binding using WS-ReliableMessaging. As with any programming environment, SCA developers must understand their technology to use it correctly.

The WS-RM protocol is not a general session management technology. Implementers of WS-RM are not under any obligation to expose the underlying WS-RM Sequence to either the sender or receiver.

Gilbert Pilz
BEA Systems and WS-RM Editor
 

Nice job!
 

To clarify my previous comment: WS-RM can be used to provide session semantics for SCA runtime implementations. One might argue that, if all you are interested in is session support, WS-RM is a fairly heavyweight means of obtaining this support. Nevertheless, the fact that WS-RM is "out there" and implemented make it an attractive option.
 

Sorry I am still confused. Exactly what problem is SCA the solution for? In what circumstances would I use SCA rather than a BPMS? How do I pass data from one component to another?
 

SCA is a foundation for creating service-oriented applications, especially applications built from distributed components. One could describe a BPMS in the same way, I suppose, although most people would expect higher-level functionality from a BPMS. A typical BPMS supports workflow (ideally both human and system), business activity monitoring (BAM), some integration capability, probably business rules, and more. SCA by itself doesn't really address most of these. Perhaps we'll see one or more BPMSs created on top of an SCA environment.

And how data is passed between SCA components can vary. Within a domain, it's typically up to the vendor whose runtime is used in that domain. In this case, a binary protocol of some kind will likely be a common choice. Between domains, it depends on the bindings the components use. SOAP will probably be one popular choice, but it's not the only possibility.
 

So an SCA component is pretty much the same as a WCF "service" and a container and a domain is just groupings of these "services" so that a SCA host can do the plumbing?
 

This is a reasonably fair assessment. SCA defines things that aren't in WCF, such as the assembly model and direct support for references, but an SCA component does have a lot in common with a WCF service. SCA containers within a domain can automatically provide lots of plumbing, too, another thing that you don't see in quite the same way in WCF.
 

Excellent introduction! It is the first and only thing I have read to date to make the "light bulb" turn on. Thank you.
 

Good article especially for the bigginers wanting to know a bit more detail about SCA;
However we have to remember that SCA primarily is being/was born to satisfy the requirement to "assemble" services into fully functional applications. Therefore I would have liked you to have focused/stressed more on the importance of using SCA for composing of the implemented services than to portray it as more of an programming model. The original intent of the original formulators is most important than the side/could be benifits of what the SCA may provide. SCA is not primarily intended for being a programming model and therefore it is a mute point to stress too much or focus or portray it as one than the original immediate benefit.
 

What's most important is whatever aspects of SCA the major vendors choose to support. My paper describes the specs, which devote at least as many pages to the programming models as to SCA's assembly aspects. And divining the intent of the people who originally formulated SCA is problematic: I know various people from various vendors who claim that role, and they all have different perspectives.

As I've argued before, I believe the SCA Java component model has significant value. As I've also noted, not every vendor shares this view, although it appears that both IBM and BEA do.

If the only benefit of SCA were its assembly model, it would be a very limited standard. This model standardizes so little: just some relatively simple XML configuration information in SCDL, and a few general concepts and terms for describing components. And within a vendor's domain, even much of the standardized SCDL gets optimized away and/or extended in proprietary ways. If this is all SCA provides, it won't reduce vendor lock-in much at all. What kind of standard would that be?
 

You are right that the only benefit of SCA is surely not in its assembly model and that there is a huge benefit from its programming model as well.
A little disclaimer - I don't belong to any of the vendor/s(not even close) that have made this very important standard happen in a short period of time. On the other hand I am a huge fan of your blogs/articles/etc.
I honestly think there is a tremendous "immediate" benefit for SCA in its assembly model. And surely there could be such a benefit in the long run to its programming model.
That is because the mega application platform vendors (ERP,CRM,SCM, SRM etc), especially SAP and Oracle are
re -architecting their applications into SOA models. I can't think of bigger projects than these in enterprise software that are in the working currently. For these kind of projects it is impossible to re-tool their developers almost entirely and immediately. Therefore the best these vendors could do is to let its developers continue to develop the services using their current well known programming model/s. At the same time they will at least need to adopt and re-tool some of their workforce to use SCA assembly model to weave these services together. Also the task of composing/assemble these services together is much less effort than the preceding step of building the services in a service oriented fashion. So it is risky and time consuming to covert their workforce entirely to use the new model.
I am not sure if IBM or BEA is having to re-architect or develop projects as big as what the ERP vendors are trying to transition to internally and therefore it is much easier for them to embrace/implement the total concept of SCA in building new projects using both the programing model and assembly model.
I think this is a big reason for the differences in their perspectives as to adopting assembly vs programming models in the near term. It may not be that they disagree about the importance of the programming model.
I strongly believe that it is only practical for adopting SCA assembly model immediately and SCA programing model in the long run.
 

Thanks David

I have read "Introducing SCA" and I have found it a very valuable descripton on this subject.
 

Hi David,

As SCA has many similarities with other technologies such as BPEL and Component-based software engineering. Sometimes it is not clear what SCA offers in special. The composition i.e. assembly model of SCA is not as strong as BPEL, because BPEL also provides programming constructs to control the flow and make decisions related to service composition. One can say that SCA and BPEL can work together as Mike Edward from IBM says .. but in that case BPEL has priority.

Any way .. I want to know what advantages SCA model has when compared to conventional component-based model?

Also, if you can kindly mention any other features that make SCA a better choice ?
 

When I first looked at SCA, I also was confused about how it related to BPEL--they can seem to address similar problems. In fact, though, SCA and BPEL do very different things.

BPEL is a programming language for defining long-running processes, i.e., workflows. SCA also defines a language, commonly called SCDL, but it's not a programming language. As you point out, it lacks constructs for control flow and lots of other things. Instead, the SCDL language is meant to describe how components written in Java, BPEL, or other languages should be assembled into composites. BPEL can't do this (at least, not in the same way that SCDL can), and so the two languages in fact don't really overlap.

If you've not already done so, you may want to read the SCA overview referenced in this blog entry. It might make the relationship between SCA and BPEL clearer to you.
 

Post a Comment


<< Home