Fabric3 - an open-source Service Component Architecture (SCA) implementations, has just announced release 1.5.
This release builds on the previous (1.4) release that implements the OASIS SCA Assembly Specification v1.1.. and provides the following new features:
- Improved clustering support including the ability to rollback failed deployments across multiple clusters and peer-based deployment
- Deep integration with WebLogic 10.3, including support for WebLogic clustering, JMS, self-tuning thread management, JMX, transactions and automatic data source discovery.
InfoQ had the opportunity to discuss this release with Metaform Systems founder and SCA specification contributor Jim Marino.
InfoQ: Can you start by explaining why we need SCA? We already have J2EE, .NET, web services, REST, JMS, etc. Why do we need another specification/implementation?
JM: In a nutshell, SCA makes writing distributed applications much easier and enables a number of capabilities that were previously very difficult or not practical to implement. SCA is a foundation for enabling and managing distributed applications. Since this is a rather vague statement, I will try and make it concrete by addressing SCA’s relationship to the technologies you mention above.
To begin, SCA’s relationship with Java EE is multifaceted. SCA fits very nicely with a number of Java EE APIs such as JPA and Servlets. In Fabric3, for example, we provide entity manager injection, persistence context management, and transparent transaction manager integration built on Hibernate. Hibernate and JPA are the most popular mechanisms for accessing relational data in Fabric3.
At the programming model level, SCA offers an alternative to EJB and other programming models. Since both programming models are designed around dependency injection, they are not radically different. However, the SCA programming model places particular emphasis on asynchronous programming and facilities to better handle remote service invocations. The SCA specification group is also working an adding support for eventing and pub/sub patterns directly into the programming model, which I think will add a number of important additional capabilities.
SCA also offers key features that Java EE and other technologies does not have - assembly and policy. Assembly is a way to compose applications from a set of services that can be local or remote. It’s similar to a Spring application context in that it is a way to wire parts of an application together. However, unlike a Spring application context, an assembly can be distributed and used to describe wiring across applications. Another feature that assembly brings is modularity. In an assembly, services can be composed of other services. This allows developers to design modular application architectures on top of a lower-level modularity system such as OSGi.
Assembly is a really powerful feature because it describes not just a single application composition, but an entire set of services in an organization that extends from a very coarse-grained to fine-grained level. We use this in Fabric3 to analyze an assembly and determine the middleware requirements of a service and dynamically provision runtime infrastructure accordingly. It is also possible to perform dependency analysis to determine which clients are using a service or if SLAs are being met. As distributed computing systems grow to thousands of services, the information provided by assemblies will be used to better manage them.
Another key feature SCA offers is cross-application policy. SCA provides the ability to define policy sets such as types of security and SLAs that can be reused across applications. Other programming models typically require developers to configure policy for each endpoint, which can be complex, error-prone, and tedious. SCA allows policies to be defined once and reused in either a "pull" or "push" fashion. The "pull" mechanism can be enabled through referencing a policy alias name via a Java annotation. The push mechanism can be thought of as a type of "distributed" cross-language AOP. With this mechanism, someone can define a policy and query expression based on XPath that is evaluated against the assembly to determine where to apply the policy. An example of this push mechanism is "enable X.509 based authentication for all deployed web service endpoints."
All of this said, SCA does leverage a number of existing technologies. Web Services (more specifically WS-*) are used for interoperability. This is particularly important for SCA services that need to be exposed to external clients, such as those written in .NET. JMS can be used for messaging between services and is important in situations where reliability is required. Fabric3 also uses JAX-RS to provide a RESTful façade on SCA applications.
I have saved .NET for last, since its relationship to SCA is potentially the most interesting. Unlike Java EE, SCA designed to be cross language. Windows Communication Foundation (WCF), which is the service-based programming model for .NET, grew out of similar requirements as SCA. Namely, Microsoft wanted to create a simplified programming model that was attuned to the requirements of building distributed, service-based applications. If one compares a WCF service to an SCA component, they are remarkably similar. In fact, most of the core concepts map directly between the two models.
However, what .NET and more specifically WCF lacks is an analog to assembly. Currently, WCF has a very "autonomous" view of services where they are created, configured, and deployed in isolation. SCA assembly could be used as a way to compose WCF services. In fact, I don’t think it is far-fetched to argue that Microsoft is better positioned in terms of SCA than many of the Java-based vendors supporting SCA. They have the CLR, which is cross language in a way that the JVM is not. In addition, . NET is a very tightly integrated end-to-end platform for application development. If a .NET version of SCA were created, it could potentially be a much more integrated and complete offering than Java-based alternatives.
The flip side to this, of course, is that SCA assembly represents an innovation beyond what .NET currently offers. It will be interesting to see how Microsoft responds.
InfoQ: Can you describe which SCA specifications are supported by Fabric3 and what is coming next ?
JM: Sure. Fabric3 currently supports the SCA Assembly, policy, Java, web services binding, HTTP binding and JMS specifications.
Two of the key features we are working on adding for our next release are support for eventing (pub/sub interactions) and Spring. The former will make it possible to create event-based architectures using SCA as well as more easily incorporate complex event processing into their applications. A number of our users in financial services are planning on leveraging this feature to analyze market data. Spring support will make it possible to wire Spring beans to remote services using SCA.
We have also been investing heavily in designing our runtime architecture to take advantage of virtual and cloud-based environments. Unlike many of the "Legacy" middleware vendors, we are not attempting to retrofit existing middleware into these environments. Moving forward, we are looking at integration with Amazon EC2 facilities such as SQS for message-based service wiring as well as non-multicast-based clustering.
InfoQ: What features beyond SCA are provided by Fabric3? How are you deciding on these features?
JM: Fabric3 offers a number of features that are typically found in commercial middleware offerings including:
- Clustering. F3 includes very easy cluster configuration, support for multi-cluster topologies and automatic provisioning of application and runtime resources to cluster nodes.
- Reliability. F3 supports XA transactions and recovery (we rely on Atomikos, which is a great product we highly recommend) and reliable deployment based on a compensation/memento model.
- Portability. F3 has a small-footprint standalone server can be hosted in a variety of application servers such as Tomcat. Our latest release provides support for WebLogic Server which leverages advanced features such as self-tuning thread management and cluster communications. Fabric3 even has embedded Ant and Maven runtimes. The key thing we are focused on is allowing applications to be deployed to any of these environments without modification.
It can be argued that the above features are to be expected from enterprise software. Fabric3 also provides a number of innovative features including dynamic wiring and policy. Applications can be re-wired and updated without forcing incurring interruptions in services. In addition, policies such as SLAs can be "added" to services after they have been deployed.
Fabric3 can be configured to automatically provision runtime extensions based on application requirements. For example, Fabric3 can figure out that Hibernate is used by a set of services and automatically provision the Hibernate runtime extension to cluster nodes when the services are deployed. This happens entirely dynamically, without requiring a restart. Similarly, when an application is undeployed, extensions can be automatically removed if they are no longer used on a node.
One of my favorite features is runtime extensibility. Fabric3 is designed around a modular kernel where capabilities such as support for remote transports and transactions are added as extensions. The interesting thing about extensibility is that is actually not "beyond" SCA. We have architected the runtime so that it is a set of SCA services. Fabric3 has a small bootstrap that reads an SCA assembly and wires services to create the runtime. This means that the runtime is extended by writing an SCA "application" and deploying it to a special runtime domain. This is what makes it possible to dynamically update the runtime with extensions; it’s virtually the same as deploying an end-user application.
Once we complete support for eventing (there is a preliminary implementation in the Fabric3 source trunk), we will be able to have runtimes create and leverage event streams. It then becomes possible to perform operations such as complex event processing on runtime events and have Fabric3 clusters adjust to varying environmental conditions.
InfoQ: Can you compare Fabric3 to other popular SCA implementations, Tuscany, for example?
JM: The Tuscany project has done a good job helping to drive SCA adoption. Having multiple implementations of a standard - particularly multiple open source ones - is a good thing as it provides choice and spurs innovation through competition.
That said, I obviously think Fabric3 has a number of advantages. These center on the enterprise features I mentioned before, extensibility, dynamic wiring, and ease-of-use. Tuscany is led by IBM and their business model is typically to up-sell customers to products that provide enterprise features on top of open source. Hence their focus is not the same as ours and will likely remain different moving forward.
InfoQ: Does Fabric3 provide an integration with any BPEL engines? What do you think about relationships between SCA and BPEL?
JM: Yes, we have a commercial partner currently using Fabric3 as their SCA platform for their BPEL product. There is also another Fabric3 developer working on integration with Apache ODE, although this is not currently available as a public download as it is still a work in progress.
In terms of the broader relationship between SCA and BPEL, the former allows services to be created using BPEL. There are a number of benefits this integration affords that are worth pointing out. From an SCA perspective, it allows developers to leverage the BPEL language for implementing process-oriented services. From a BPEL perspective, SCA provides an easy way to write parts of an application that more suited to traditional programming languages such as Java. Without SCA, for example, accessing Java code from BPEL has to be done using Web Services or a proprietary vendor integration mechanism. SCA standardizes this, makes it easy to access Java without the overhead or complexity of Web Services, and provides a way to deploy BPEL and Java components as a single unit..
InfoQ: What specific provision does Fabric3 have for automated deployment?
JM: Fabric3 provides a number of advanced deployment features. As I mentioned earlier, F3 automatically provisions application archives to nodes across multiple clusters. This can include transitive dependencies as well. Also, since the runtime is built using SCA, it is possible to provision required runtime extensions (and their dependencies) along with an application using the same mechanism.
Another interesting feature we added in our 1.5 release is compensation-based deployment. If a deployment fails, a node will be rolled back to its previous state. In Java EE where deployment units are mostly autonomous archives, this is not as difficult a problem to solve. However, in SCA, where services in one application may be wired to services in another application, maintaining runtime consistency is challenging. For example, if an application deployment fails, any changes to services in another application such as dynamic wiring need to be undone. Fabric3 uses a compensation approach based on the concept of memento to undo changes. The upshot is that runtimes are always left in a consistent state.
InfoQ: How does Fabric3 implementation address load-balancing and failover?
JM: Load balancing in Fabric3 is handled at the transport layer. Over web services and POX, F3 relies on HTTP load balancers. For messaging, F3 relies on the messaging provider such as a JMS implementation.
Fail-over for stateless services is straightforward - Fabric3 clusters them so there is nothing sophisticated that needs to be done. One of the things we are working on is support for clustered singleton services. Our goal is to allow users to specify a clustered singleton using an annotation and custom SCA scope.
Conversational services are obviously trickier. The BPEL implementations we have worked with rely on a database to replicate state. We haven’t yet implemented fail-over for Java-based conversational services yet, although it is on our radar.
InfoQ: What kind of versioning is supported by the Fabric3 implementation?
JM: For artifact versioning, Fabric3 relies on SCA’s import/export mechanism, which is partially built on OSGi. For Java artifacts, SCA supports OSGi version ranges. For XML-based artifacts such as WSDLs and XSD, SCA allows archives (called contributions) to import and export namespaces. If a contribution imports a namespace, it will be matched against other contributions that export the namespace. Artifacts under that namespace in the exporting contribution will be made available to the importing contribution. To version XML artifacts, the version has to be encoded in the namespace declaration. The SCA import/export mechanism is therefore a superset of OSGi import/export feature.
For service versioning, Fabric3 supports the ability to deploy a service to multiple endpoints. It is also possible to introduce a form of ESB mediation where a single endpoint proxies multiple versions of a service. We haven’t done much with this latter approach, but the F3 architecture supports it.
InfoQ: What kind of tooling does Fabric3 provide?
JM: Nothing directly. However, the Eclipse STP project now supports Fabric3 extension syntax in their modeler. We are also planning on working closely around support for policy definitions.
I should also mention IntelliJ contains nice refactoring capabilities for SCA XML assemblies such as automatic renaming in XML when a class is renamed or its package changes. I think this is a feature that "just works" as I am not aware of JetBrains having worked on specific SCA integration. It’s probably just a case of having an elegant, generalized design for the IDE.
InfoQ: What would you recommend readers that want to start experimenting with Fabric3?
JM: Start with our samples and posts to our user list. Our goal is to have a helpful, friendly atmosphere for working with Fabric3.
