Service Component Architecture? I am a HUGE fan!

The OASIS work on Service Component Architecture really fills an important niche in the pragmatic side of SOA. It is probably the most concrete and pragmatic work for companies to use when taking real steps towards SOA nirvana. SCA is composed of a set of specifications that are very closely aligned with and build on the OASIS Reference Model for SOA.

Imagine this scenario. Your CTO/CIO comes back from some conference and blurts out, "We have to do SOA. All the cool companies are doing SOA!" As an architect/developer the question looms: "What does this really mean?. Sure you can use the abstract Reference Model as a basis for an intelligent conversation on SOA but organizations really need something more concrete to take steps in the real world.

SCA is your answer. The work, originally from the Open SOA Alliance, is now under the auspices of OASIS. SCA is a set of related specifications which describe a model for building applications and systems using a SOA. It is based on business functions being provided as a series of services, which are assembled together to create solutions that serve a particular business need. SCA describes how services are based on a set of related business functions on two levels, one abstract of the actual binding. This is highly advantageous in order to preserve the lexicon of service definitions independent of the specific bindings used.

SCA extends and complements prior approaches to implementing services. Extensions include a programming model for building applications and systems based on open standards such as Web services as well as specific programming languages. The models should be highly effective for business stakeholders and technical stakeholder to align and describe services at various levels of abstraction including their purpose, interfaces and capabilities.

It's important to note that SCA is actually expressed as a group of related specifications, ranging in levels of abstraction from mid-level models to concrete bindings to several specific programming languages (Java and C++ were first).

Adobe has recently joined this effort within OASIS. The work is very relevant to our service oriented platform (LiveCycle Enterprise Suite or LC ES) architecture. In fact, many of the core tenets of SCA assembly have been inherent in LiveCycle ES's design for a while. We use many concepts similar to the service descriptions within the registry-repository component of LiveCycle ES. This allows people to use tools like the LiveCycle Designer and Workbench to assemble services into functional processes and aggregate applications.

I am looking forward to participating in this great work done by IBM, BEA, Oracle, Fujitsu, Hitachi, Red Hat, SAP, TIBCO and many others.

Adobe MAX 2007 is now SOLD OUT!

My colleague Ted Patrick (ATE) was put in charge of MAX this year to get it more in alignment with developers, architects and other technical personalities. Ted is a rabid over-achiever who strikes me as the type of person who has probably never failed at any job. His mandate was to grow the MAX event from around 3,000 attendees by ten percent.

Today he sent an internal email that indicates the seemingly impossible has happened:

We shut down registration last night for MAX due to high number of attendees and our ability to deliver the conference.

First time MAX has "SOLD OUT"!

Ted :)

We are officially sold out. Ted rules! For those of you lucky enough to have registered in advance, this year's gonna rawk!! OMG!! Really, really rock!

For those who did not get in this year, I've already started a wish list for MAX 2008 here. Next year there are several things people want:

1. An earlier call for papers
2. Hold the conference on the east or west coast. Maybe we should alternate?
3. More external speakers
4. More technical sessions
5. No marketing fluff