BEA has released a Technology Preview of SCA support in WebLogic 10.3 based on the open source Fabric3 runtime. InfoQ spoke with Jim Marino, Directory of Technology at BEA Systems and one of the original SCA participants and Fabric3 contributor, and Meeraj Kunnumpurath, Lead Technologist at VocaLink, and who has been involved both in the SCA specifications and the implementation of Fabric3.
InfoQ: There has been a lot going on the past 10 years with SOA, what is your perspective on the evolution of the software industry towards SOA?
Meeraj: From an end-user perspective, we are interested in solving increasingly complex business problems. Vocalink is one of the biggest interbank payment processors in the world. We have been in this business for 40 years. Today we see a lot of business opportunities, mostly in Europe. These new opportunities require that we reuse our software assets to build new solutions. This is where we see SOA as being key to reach the new business opportunities. For us, SOA enables us to improve our total-cost-of-ownership and develop news solutions.
Jim: To echo, Meeraj's point, the main problem we see customers having is the difficulty reusing code. Object oriented technologies introduced significant improvements for code reuse within an application., However, code reuse across process boundaries has been much more problematic. Remoting technologies such as EJB or CORBA mistakenly attempted to apply O-O principles to interprocess communications. With SCA we are taking a different approach to this problem. SCA introduces a programming model that embraces O-O for in-process calls but provides facilities for asynchronous, loosely-coupled interactions for remote operations. As a lot of existing programming models have grown in complexity, with SCA, we are aiming at a programming model that reduces complexity while at the same time providing for modularity through composition, which is a key concept..
InfoQ: How is the adoption of SCA today?
Meeraj: We would like to see more effort from the vendors to promote SCA. In the last 3 or 4 years, SOA has evolved to become a major paradigm to build solutions. But for the most part, SOA has remained a set of patterns and best practices, sometimes difficult to implement. At the same time we have seen developers being burned by container based technologies and turned to lighter weight programming model such as Spring or Mule. However, these technologies remain proprietary, they lock you in. SCA is bringing a new light weight programming model, but this time, it is standard-based, you are no longer tied to a particular vendor. SCA provides a prescriptive set of specifications on how to build SOA-based enterprise applications.
Up until now, our SOA implementation was based on Spring and Mule. We are now migrating towards WLS 10.5 and leveraging SCA which fits our needs in terms of modularity, composition, policy enforcement and ultimately reuse. For us, this is a fantastic step forward, this is a technology that needs to be evangelized and we would like to see a lot more effort from the vendors.
Jim: I agree with Meeraj, we haven't done a very good job at explaining what SCA is. Even though it is starting to gain more momentum, it is small if you compare it to the early hype around EJB. One of the problems is that there have not been any mature runtimes until now. With Fabric3 and Apache Tuscany maturing, both open source projects, we should see a lot more interest in the technology. I would also argue that the current technology environment is different. There is a slower adoption rate for new technologies. Overall, this could turn out to be a good thing if we can evolve SCA carefully and avoid rushing the technology to market.
Meeraj: I would say that there is still a good level of interest for new technologies as long as they solve problems, for instance, we have seen technologies like Spring emerging with a significant market presence.
InfoQ: Speaking of new technologies, OSGi seem to be emerging as well as an important technology, how do you position SCA and OSGi?
Jim: OSGi a great technology and BEA is a strong supporter. OSGi and SCA can be complementary. For instance, an SCA runtime can run in an OSGi container such as Equinox or Apache Felix. However, it is also important to recognize that OSGi does not address all modularity needs. To provide for better application modularity, SCA has composites and contributions. I’d like to talk a bit about contributions, since they are one of the major changes we have made recently to the SCA specification. Contributions are the way to install and share application artifacts in SCA. The interoperable packaging format specified by SCA is a zip file such as a JAR in a Java runtime. We thought about the option of using OSGi bundles, but we were not able to do that: OSGi is really about a single process, a single JVM. SCA needs to deal with the distributed case. In addition, SCA isn't just about Java, and needs to handle the sharing of non-Java artifacts such as WSDL documents and XML schemas. So we came to the conclusion that we needed to develop this notion of contributions, which handle packaging and sharing in a distributed environment.
That said, one of the interesting aspects of the SCA contribution mechanism is that it is extensible. This allows an SCA runtime to support OSGi bundles as a contribution packaging format. Similarly, an SCA runtime could also support other packaging formats such as WARs or EARs.
Meeraj: We have been looking at OSGi and Spring Dynamic Modules. We found that there is a lot of overlap between OSGi and SCA. SCA promotions for instance have parallels in OSGi, and so do SCA contributions. However, transport abstractions and the policies have no equivalent in OSGi, as far as I know, even though there are some related initiatives within enterprise OSGi. These features are a huge value for building enterprise middleware applications. What we experienced is that SCA really embodies the way we should be building SOA applications: it becomes easier to implement SOA idioms and patterns, and there is a strong emphasis on typed service contracts. At the same time, SCA gives us the freedom to move our code to other SCA containers in the future.
InfoQ: What has been your approach for adopting SCA?
Meeraj: We are in the process of moving applications from mainframe to midrange servers, using a Java based environment. We have experienced two distinct phases: first using heavy weight technologies like EJBs, then we turned to lighter weight technologies such as Spring and Mule. Now, we are experiencing more intricate problems, in terms of modular compositions, policy enforcements, transport abstractions and heterogeneous federation. Spring has been great for us, however, SCA addressed a lot more intricate enterprise software engineering concerns than Spring or Mule.
That's when we turned to SCA. I started getting involved with Tuscany and later on took a more direct role when I started to work on Fabric3. This gave us a close view of the technology. We are considering using SCA on 2 projects. This was a well informed decision because of our involvement with the OASIS TC and the Fabric3 project. We don't have any system in production yet, of course, but we have plans to release these two systems in Q4 this year using Fabric3 in a J2EE container.
The projects are a mixture of legacy and new code. Most of the existing code was built on technologies like Spring. For migrating the Spring beans to an SCA environment, it was basically taking them and adding SCA annotations. Fabric 3 also suports a lot of heuristics for enabling running legacy code as SCA components. That was that simple.
Spring allowed us to do dependency management, so we could run our code outside a container, then change the configuration and run in J2EE. Spring laid the foundation for using lighter weight programming models at VocaLink. However, we find SCA addressing the intricacies of component orientated software development better. One of the key requirements for us has been enforcing component encapsulation. There is no way I can compose a series of Spring beans as a component and simultaneously express that some of the beans are private to this component. SCA is very good at managing this distinction and promoting only those aspects of a composite intended for usage outside the composite and leaving everything else private to that cmposite. In addition, SCA policies are a lot more expressive for enforcing QoS aspects. SCA intents are abstract requirements that can be mapped to concrete policies in an operating environment. For us, we see SCA addressing a lot more issues that Spring used to, in a standard-based way. And implementations like F3 do this without compromising on light-weight development model and developer productivity.
Jim: SCA is being embraced by a number of BEA products. We are working on general availability of SCA support in WebLogic,. WebLogic Server embeds Fabric3 as a first-class container in the same way as JEE support is incorporated into the server. This allows users to install Fabric3 extensions such as bindings, policies and support for alternative component implementation types on WebLogic Server. It also allows users to create custom extensions that can be installed wherever Fabric3 is embedded, whether in WebLogic or another server such as Tomcat, Jetty, or an OSGI-based runtime. WebLogic Server adds features such as clustering, management, fail-over and reliability. We also have SCA tooling initiatives underway for developers and deployers .
InfoQ: Could you provide some perspective on loose coupling and SCA?
Jim: SCA’s programming model is designed specifically to promote loose coupling. In Java, SCA has made asynchronous interactions, callbacks, and conversations first-class citizens. As Meeraj mentioned previously, SCA also provides protocol abstraction so that code does not need to deal with low-level transport APIs when making remote calls. This allows for a form of loose-coupling that is removed as much as possible from transport specifics.
Interestingly, though, SCA also has support for more tightly coupled, local interactions. This is because loose coupling is not appropriate at all levels of application design. Dealing with remote asynchronous interactions, for example, is generally more complex than handling synchronous local ones. Through its notion of composites, SCA allows loosely-coupled services to be assembled from a series of smaller, tightly coupled components. This helps promote application modularity as services are composed from smaller units that are managed together as a composite. It also helps reduce complexity as the remote, asynchronous calls can be limited to key parts of an application.
InfoQ: How do you envisage to deal with Management & Operations in SCA?
Jim: This is an area that has been identified as an area of future work. From a BEA perspective, we are looking at SCA and the assembly model as a way to greatly enhance management, since the latter provides a unified way to represent runtime environments consisting of disparate technologies.
Meeraj: Conceptually there are two aspects of SCA that leads to ease of management. The concept of a domain, which provides a unified view as Jim pointed out. There is also the concept of recursion which is important. Recursion allows defining policies higher up in a domain and enforce them on all the component implementations and interactions within. Fabric3 puts a lot of emphasis on supporting heterogeneous federated domains. So, SCA provides the foundation for managing complex connected systems, but yes, we need to go farther to support concrete mechanisms to support management & operations.
InfoQ: What are some of the difficulties you encountered in adopting SCA?
Meeraj: The lack of mature products definitely, but for us SCA is a significantly step forward for building SOA applications. The specification is still 1.x level and will be evolved. There is a wide participation, not just from vendors. In the TC, we are providing and getting practical feedback and facing real-world issues: how policy works in certain scenarios compared to what is specified now. It is an extremely positive environment to work in.
InfoQ: What are the key benefits of SCA?
Meeraj: Generally, if you compare SCA with other technologies it does not tie you with a given technology. You can use a wide variety of component implementation technologies like Spring, Java, BPEL, scripting etc and a variety of transport mechanisms like HTTP-WS, JMS, RMI, Hessian, AMQP etc. SCA also addresses a wide range of concerns that are important for us: assembly, composition, transport abstraction and bindings, intents and policies, domains... For us, SCA offers still a light weight programming model but solves a large set of intricate issues. We really would like to see more evangelization from the vendors, and help their customers embrace these technologies.
Jim: SCA is really the next step for application development. SCA represents some very concrete steps for what people often vaguely describe as “SOA”: reuse, composition, policy administration, and loosely coupled services. The overarching benefit of SCA is that it attempts to provide these features in a way that is a lot simpler than traditional approaches. .
Meeraj: SCA is not just about realizing the stereotypical view of SOA: not everything is loosely coupled or stateless. At certain levels of your enterprise applications you have tightly coupled fine-grained components, you often have stateful conversations, you do need support for conversational callbacks etc. SCA talks about how do you build these SOA-based applications: you build them recursively. SCA really represents a set of specifications that prescribes how you build SOA-based applications.
