David Chappell

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