Posted by edort
on May 17, 2006 at 1:19 PM PDT
I just came back from a technical session on the SCA architecture titled "The SOA Programming Model". That session title suggests that SCA is the one and only SOA programming model. Well, it is a programming model for SOA, but certainly not the only one.
I had two initial thoughts standing in line waiting to get into the the technical session "The SOA Programming Model" (TS-3608): 1. Wow, there's a whole lot of people in this line -- who knows, maybe SOA has progressed from the "what the heck is it?" stage to the "I'm actually doing SOA-related coding" stage; and (2) Why is this session called "The SOA Programming Model"? The abstract says it's about Service Component Architecture, "an" SOA programming model, not "the" (one and only) SOA programming model.
O.K. so much for initial thoughts. What I really wanted to get out of this was a better understanding of what SCA is. The abstract for this session said that the session would cover "how the Service Component Architecture (SCA) and Service Data Objects (SDO) form the basis of a cross-language and cross-technology representation of service components and the data exchanged between those components for SOA-based applications." I translate that as "we'll tell you what SCA and it's data partner SCO are and how they fit into SOA." I don't know how or why, but somehow I'd been led to believe that SCA was somehow in competition with the architecture I envision what I think of SOA, an architecture that's built on a foundation of specific protocols and web services technologies.
What I think I learned in this session is that SCA is essentially technology agnostic. In fact the main speaker in the session, IBM Distinguished Engineer, Rob High, who's on the team working on the SCA spec with folks from BEA, Oracle, and SAP, painted a mental picture that SCA is all about building SOA at a much higher level. (Had a funny thought there -- High talking about thinking "High"er.) High said that "we tend to think about SOA as a technology. But we've got to think about it as an alignment between business goals and IT." High said that SOA is really a style of building an enterprise architecture that's derived from business design. In other words, the goal of SOA is to automate a company's business processes so that it can meet its business goals and flexibly respond to changing business goals and needs. It's not about the technologies and languages that are used to implement SOA.
So what's SCA and SOA? High did go over (too quickly for me to grasp in any real sense) some of the terminology and concepts that underlie SCA and SOA. I did pull the following definition off of one slide in High's presentation:
Service Component Architecture: A specification which describes a model for building applications and systems using a Service Oriented Architecture (SOA).
Hmmm, seems sort of circular. So I'm going with the thought that SCA is an architecture that's driven by the underlying processes of a business. One thing I did get a better insight into in this session -- something that's not really specific to SCA or SOA -- is what Web 2.0 is really about. I've yet to see a really cogent definition of what Web 2.0 is. High said that "Web 2.0 expresses a desire to enable the truly ad hoc -- the ability on the Web to do what I want and need to do without the constraints of system conformance. It's all about dynamic interaction and social networking on the Web."
There was a question and answer session at the end of the talk. High invited SCA team representatives from BEA and Oracle to join him in answering the questions. Dissapointingly (at least for someone who's hoping that people are really interested in SOA) about three fourths of the audience left before the first question was asked. My take based on the answers to some of the questions is that the SCA spec is still far from finished. Major areas still need to be addressed such as how services implemented as enterpise beans fit within the architecture. I was also a little bothered by the vagueness of some of the answers. For instance, someone asked how to identify the "real" services in a legacy application. The answer given was essentially that it's difficult and requires the use of business modeling tools and people with business expertise. Another asked about the status of BPELJ (BPEL for Java technology). The answer was that BPELJ is in whitepaper stage and no spec yet exists for it.
I guess I came away from this session with some notions about what SCA is but not really all that clear of an idea. I guess I'll have to do some research on it.