Tuesday, March 11, 2014

Fuse Service Works and SCA

Fuse Service Works contains three main components - Core ESB based on JBoss Fuse, Service Framework based on Switchyard and Governance based on Overlord.  Switchyard is a lightweight service delivery framework providing full lifecycle support for developing, deploying, and managing service-oriented applications.

Switchyard is a implementation of some of the SCA specifications.  The Switchyard Designer below shows an example of a Home Loan Application with the Services/References/Bindings.

Service Component Architecture (SCA) is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture (SOA).  SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.  This diagram shows services and references in relation to bindings.

Open CSA oversees the work of several OASIS Technical Committees on SCA that address the following specifications:

• SCA Assembly Model
• SCA Policy Framework
• SCA Java Annotations, APIs, and Component Implementation
• SCA Client & Implementation: C++
• SCA Client & Implementation: BPEL
• SCA Client & Implementation: PHP
• SCA Client & Implementation: Spring
• SCA EJB Component Model
• SCA Bindings Specifications

SCA essentially standardizes a conceptual model for the definition, structure and implementation of service-oriented applications.   Even though the standard is defined there is no guarantee of interoperability or portability for applications across different vendors which are developed for an SCA runtime.  So there is a big advantage in having the shared conceptual model between implementations as the user's view of the application will be similar across them.  The  implementation of the specifications that Fuse Service Works v6 follows are based on the merit and relevance of the specification and the ability to deliver it in the product.   There are some parts that are useful which we have not implemented yet and others that customers may request which we can take on as feature requests.  So the product team will continue to fill out our support for SCA specs as it makes sense for the product platform.

One thing to keep in mind is that the list of specifications are in very different states of maturity. At this point Assembly is the most mature.

There is not a master list of what's implemented and what's not.  If there is something specific that is needed it is best to get an idea of what they're using and we can help line that up with what we have.

SCA Assembly Model

This is where the product team invested the vast majority of our time as it represents the configuration model for the application.  The coverage is not complete, but it is substantial.  The most notable section missing right now is around packaging and deployment.  We have our own packaging model which allows for JAR/EAR/WAR deployment at the moment.  That said, there are certain elements of the SCA packaging model which are attractive to us (e.g. recursive composition) that may make it in a 6.x release of FSW.

SCA Policy Framework

This is partially supported.  SCA Assembly pulls this in and we support the transaction and security policy sections of this specification.

SCA Client & Implementation: BPEL

BPEL deployments within a Switchyard application use the standard BPEL schema from this spec. 

SCA Java Annotations, APIs, and Component Implementation
SCA EJB Component Model
SCA Bindings Specifications

We have our own implementations of these via the standard SCA extension mechanism.  If customers are really interested in the standard version of these, we can always have a look.

SCA Client & Implementation: C++
SCA Client & Implementation: PHP
SCA Client & Implementation: Spring

No plans to do anything with these at the moment.