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: PHP
SCA Client & Implementation: Spring
No plans to do anything with these at the moment.
