In this interview we talked to Mike Edwards (IBM), Steve Jones (CapGemini), David Burke (TIBCO), Sanjay Patil (SAP) and Michael Rowley (BEA).
Michael Rowley works on standards in BEA's office of the CTO. He is currently one of the 7 elected members of the OASIS steering committee for the Open Composite Services Architecture (OpenCSA) Member Section, which is overseeing the standardization of SCA and SDO. He is co-chair of the SCA-J TC (for the SCA Java specs) and one of the editors for the SCA Assembly and SCA BPEL specifications.
Steve Jones is currently Head of SOA and SaaS for Capgemini's global outsourcing business and was the Global Product Director for the recent launch of their partnership with Google. He has been a member of several JCP groups including the original JAX-RPC group, JBI (1 & 2) and JavaSE 6 and is Capgemini's executive sponsor of the JCP membership. Steve is also the sponsor for Capgemini's engagement with OASIS where he has been a member of several groups including the SOA Reference Model and eGov groups and most recently in Capgemini joining the Open CSA group. He is also the author of the InfoQ book "Enterprise SOA Adoption Strategies".
Sanjay Patil is a Standards Architect at SAP Labs, Palo Alto, and is an active member of many standards bodies including OASIS, WS-I and JCP. He currently co-chairs the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee and the OASIS Service Component Architecture BPEL Technical Committee. His areas of interest include Web services, SOA, Composition Technologies and Java EE.
David Burke is a Director, Product Management at TIBCO Software, and serving on the OASIS OpenCSA Steering Committee, advancing the SCA and SDO families of SOA specifications.
Dr Mike Edwards is a Strategist working on Service Component Architecture at the IBM Hursley Park Lab in the UK and is currently co-chair of the OASIS SCA Assembly TC. Mike has worked in software development for 25 years, and past exploits include OS/2 Presentation Manager, CallPath computer-telephony integration, Java and Web services.
InfoQ: Why do you think it has taken so long for SCA to get to a standards body?
Mike Edwards (ME): I don't think that SCA has taken long to get to a standards body. SCA started from scratch to address problems and opportunities in the SOA space. It was evolved by a group of collaborators and this involved not only creation of the specifications but also implementations in parallel to check the specifications and provide useful feedback. Only once the specifications were mature and we had the confidence that the specifications were pretty solid did it make sense to move forward to a standards body. That time is now.
Steve Jones (SJ): I'm not sure that it really is that long a time. I remember when JBI kicked off and that was around the same time as SCA & SDO were starting so given that JBI 2.0 is starting in the JCP then having SCA arriving now doesn't seem that long a period of time. In effect there is an SCA 1.0 in the same way as there was BPEL 1.1 before it arrived at OASIS.
David Burke (DB): Actually, from our point of view, SCA's arrival to a standards body has been quite timely. Relative to the industry, SOA is fairly recent and SCA as related standard has come along quite quickly compared to, for example, the time between the interest in query languages in the early 1970s and the first ANSI SQL standard in 1986. Also interesting to note is how SCA came about as a co-opetition effort first and then moved to a standards body, a sign, I think, of the growing maturity of the industry overall.
InfoQ: Why OASIS and not W3C?
SJ: OASIS are about business and implementation standards more than W3C. SCA is a business standard and its about implementation so OASIS makes more sense.
ME: The choice of a standards body to use for any specification is not a straightforward one. However, SCA is primarily about a programming model, rather than on-the-wire protocols, and we felt that OASIS has a good track record in this area - for example the WS-BPEL specification - and that OASIS also offered a structure well suited to the parallel group of technical committees that SCA needs.
DB: When you look at the standards activity within the two organizations, OASIS is a better fit for SCA. OASIS is focused on web services and business level interoperability, which fits well with the goals for SCA.
InfoQ: Why is SCA-J not being worked on within the JCP?
SJ: This is something we at Capgemini would like to see happen. Having SCA as a part of a future J2EE specification would, for us and our clients, make sense. Clearly there are political problems between the vendors and it would be nice to think everyone could start being mature about this.
ME: SCA as a whole is not a Java specification - it is an SOA specification spanning many techologies both Java and non-Java. It did not seem to make much sense to split away the SCA Java specifications from the other SCA specifications, making liaison between the Java group and the other groups more difficult. It also keeps all the SCA specifications available under one, easy to understand license.
DB: To a large degree, SCA-J avoids trying to describe the environment in which Java code runs. Questions around how SCA-J services run could be, and maybe should be done as part of a JCP process. SCA-J instead focuses on how Java services are consuming and consumed by other services, written in Java and not. Some small portion of this work, then, looks at how Java works, and how it wants to affect the bigger picture of what SCA does. From that perspective, the SCA-J team needs to make sure that Java developers find it easy to write SCA services. Most of the work, however, is about how to map SCA Assembly and Policy questions on to Java, and from that perspective, the SCA-J team really is looking at how to map language independent notions onto Java, while those language independent notions are still evolving. Thus, while it might be possible to manage Java specific work as a separable piece, inside the JCP process, for the time being it makes more sense to have it as a equivalent peer of those other specifications in a single standards organization.
InfoQ: If you had to summarize what SCA brings to this space in two sentences, what would they be?
SJ: Contained Design and Deployment. A single approach to creating and packaging complex applications.
ME: A language for describing composite services applications. A simple approach to the construction of service components, concentrating on business function and keeping infrastructure concerns well separated.
DB: How about two words? Developer mind-share. To elaborate a bit on that, SCA provides developers with a standards based approach for composite application development.
Michael Rowley (MR): I would describe it as technology for creating, assembling and deploying service-based applications out of multiple languages and multiple communications protocols. Our most important design principal has been that the technology should be as simple as possible, even if it means sacrificing some functionality for simplicity when the two are in conflict.
InfoQ: Why is your company interested in SCA?
DB: In looking forward to its next generation of products, TIBCO found that internal proprietary approaches were starting to look a lot like some of the key concepts in SCA. Once we realized that, it made much more sense for us to go down the path of working with others to develop a set of standard. Obviously, we're still concerned about some aspects of the standard, and have some work to do on our products to implement the specifications that we think make sense to our customers.
MR: BEA believes that the industry is moving away from pure Java server-side applications to a model where applications are built out of a variety of higher-level technologies, such as BPEL, data integration technologies, XPDL, ESB pipelines, etc. We also believe that users want the composite services that bring these technologies together to be specified declaratively, in XML, rather than through APIs and programming. However, there will still be many critical leaf-level services created in Java. SCA makes it possible to create and deploy these mixed-technology applications in a standard way. It also provides a Java programming model that allows services to be written without limiting the transport technology that will be used to communicate with the service, which fits well with SCA's assembly model.
ME: We believe that SCA is an important building block in the use of SOA to build business applications. It will make SOA more consumable and it will create a common pool of skills that companies can draw on to build their systems.
Sanjay Patil (SP): We would like to second that and would like to add that we believe that SCA provides a framework suitable for integration with existing runtime and deployment technologies such as Java EE and OSGi.
SJ: We build and support a huge amount of systems for our clients, this helps us do it better. We were involved with IBM on the first beta release of SCA and we are using it commercially with clients today, its a strong approach and fits well with our business driven view of SOA.
InfoQ: Do you see any overlap between SCA and JBI?
MR: Technically there is no overlap. JBI can be used as the infrastructure for creating runtimes that can deploy and execute applications described using SCA composites. However I'll be a little controversial and say that there is some question, in my mind, about whether JBI is the best technology for accomplishing this. JBI is based around a messaging paradigm that makes routing and processing decisions on normalized messages at runtime. However, SCA makes it possible to use a more efficient infrastructure where the routing and binding decisions are determined at deployment time so that message communication can occur without normalization and with a minimum of infrastructure overhead. This is one of the reasons that neither of the open source SCA runtimes that I'm familiar with (Fabric3 and Tuscany) have been based on JBI.
ME: In a word, no. SCA is primarily concerned with building end-user applications using a very wide range of technologies. JBI is more concerned with building the infrastructure for heterogeneous service applications on the Java platform. SCA can be used on a JBI runtime, but it is also possible to use SCA without JBI and JBI without SCA.
SJ: JBI is engine-to-engine, SCA wraps up the code in the engines. There is a risk that the two start duplicating but we have fed back to the involved parties for several years that we think there would be benefit on the two groups working together.
DB: SCA looks at defining abstract notions of service invocations at design-time, whereas JBI defines APIs for service invocations at run-time. Some of the concepts clearly align, but the overlap, if any, is minimal.
InfoQ: Is there an equivalent of SCA within Microsoft's arsenal of SOA technologies?
ME: Windows Communication Framework (WCF) has some of the features of the SCA service component model, but there is no real equivalent of the SCA assembly model for the composition of applications.
InfoQ: How do you see SCA evolving now it is in a standards process? Will it change much, or do you think it is close to being complete as it is?
ME: Our expectation is that SCA will not change a great deal from the current 1.0 specifications. The major task of the OASIS technical committees is to create detailed conformance statements and associated test suites that will help assure portability and interoperability between conforming implementations of SCA from different suppliers. That is going to be something of real value to end-users.
SJ: I'd like to see a first standard out quickly so we can have something with broad adoption. Then we can start focusing on what is next. SCA isn't finished by any means, there are lots of enterprise problems it could be extended to, but it would be better to iterate a specification than wait until we've boiled the ocean.
DB: Since there are currently six TCs at OASIS, it is difficult to make generalizations about the SCA specifications as a whole. Some of the specifications are clearly more mature than others. We can be fairly certain that the companies involved, collectively, will react to customers. Since the specifications are now "1.0" level and publicly available, hopefully we'll be getting feedback from real customers about what is most important to change. In the near-term, nobody expects an SCA Composite written for one vendor's tools to work seamlessly with another vendor's tools, any more than in the early days of SQL, SQL statements written for one database would work with another vendor. Customers, of course, will certainly highlight some areas of further compatibility as more important than others.
MR: I believe that the major ideas in SCA have been fairly well thought out, so I'd be surprised if they changed much. However, I also believe that the OASIS TCs will not just be hardening the design decisions that have already been made, but will be able to make significant improvements to the design as well. The TCs will also have the benefit of the OASIS members that have gained implementation experience with the SCA 1.0 specifications and will have feedback from the efforts to create test suites for the technology.
InfoQ: One of the objections to SCA that was leveled early on was that it competed against JEE. Now that Sun are involved it would see that any such comments were unfounded. Is that correct?
ME: It is perfectly possible to use JEE components and applications within an overall application composed using SCA, where other technologies are also used. SCA even has a specification for doing this. So I'd say that SCA works with JEE rather than competing. SCA does acknowledge that there is more in a typical business environment than JEE - that is verymuch part of the world of SOA.
DB: I think some of those early objections arose from a less than full understanding of SCA and its goals. JavaEE may have a lot to offer for enterprise applications, but when you look at the bigger picture for end to end business solutions, in the context of SOA, or composite applications, there is a need for more facilities and capabilities than JavaEE provides, elements that are beyond the scope of JavaEE.
SP: We see SCA as a valuable addition to Java EE. It will preserve the Java EE investment for developers and vendors, and at the same time provide a framework which allows plugin of new component models. In order to do that, we want to create an evolutionary model for SCA that makes Java EE more SOA ready by extending the Java EE application model and allowing access to new implementation technologies (such as BPEL for example) and new protocol bindings. We see a model that allows enhancement of Java EE applications with SCA artifacts and artifacts of other, SCA-supported implementation technologies in one assembly.
SJ: We use SCA on J2EE, I've always been very confused by people who say that.
MR: "I'd say that there is some overlap with some parts of JavaEE, but not with most of it. Imagine a JavaEE application created out of EJB session beans, JAX-WS (or JAX-RPC) services, message driven beans, and some deployment descriptors. It should be possible to create that same application by creating component implementations using SCA's Java programming model and configuring them using SCA's composite files. The runtime might still use JMS and one of the JAX SOAP stacks, but their APIs would not be visible to the developer.
Areas where there is no overlap include the JavaEE technologies for the presentation tier (servlets, JSPs, JSF, etc) or the data tier (JDBC, JPA). Technologies such as JCA and JMS still get used, but their APIs are not use directly by the component developer. Instead the infrastructure uses those technologies to provide configurable bindings that provide access to back-end systems or messaging systems, respectively.
InfoQ: Are there other areas of SCA that have not yet reached a level of maturity for donation to OASIS? If so, can you give us an idea of what they might be?
ME: The Open SOA collaboration is continuing to discuss aspects of SCA that have not reached maturity. Some will directly be part of the OASIS technical committee discussions. Examples include a Pub/Sub and Eventing model for the Assembly specification. Others, such as the relationship of SCA to management facilities and SCA specifications for some Scripting languages are at a much earlier stage of discussions and will evolve initially outside OASIS until they are suitably mature.
MR: Another area where we expect the OASIS TCs to do work, but where we don't yet have an input document to provide, is a specification describing how JavaEE applications can be integrated with SCA. We do, however, have a Wiki page that describes use cases that we care about.
InfoQ: Is you company an SCA developer, user, or both?
MR: BEA is an SCA developer.
ME: Both. IBM builds products that provide SCA, but IBM also has a services arm that builds solutions using SOA for our customers.SP: SAP is an SCA developer.
DB: TIBCO is an SCA developer, providing products that our customers can use to build SOA based solutions.
InfoQ: Where do you see SCA fitting within your company's SOA strategy?
SP: Simplification of design and deployment of composite applications is an important factor in realizing the benefits of Enterprise SOA. Service Component Architecture (SCA) aims to achieve the simplification of SOA-based service composition. SCA also has a great potential to provide standards based extensions of SAP NetWeaver with various application programming models and communication mechanisms used by our ecosystem of partners and customers.
SJ: As part of the technical delivery of Business SOA. It fits within the design, implementation and deployment phases.
ME: It is an important aspect of the core products that support building SOA applications.
DB: As we see it, SCA is "the only game in town" right now for SOA. We're significantly investing in SCA for our SOA strategy.
MR: We see it fitting in in two basic areas. One is that it will be integration technology that will simplify the development, configuration and deployment of applications that use multiple BEA technologies from our AquaLogic and WebLogic product lines. It will also provide a new simplifed programming model that allows new services to be created in Java and deployed in WLS.
InfoQ: Why isn't Microsoft involved? Since SCA is supposed to be language agnostic and embraces many of the WS-* technologies that Microsoft has been involved with, it would seem that their support would be necessary to make this a meaningful standard?
ME: Microsoft are free to join the OASIS SCA activities at any time and we would welcome them. SCA is a meaningful standard without Microsoft's involvement and SCA is able to support implementations on the Microsoft platforms, even if not supplied by Microsoft.
DB: As to Microsoft's involvement, clearly it would be best for Microsoft to answer on their own behalf. However, to hazard a reply, I think Microsoft's first priority would be their homogeneous environment and their customers that have made significant investments in that technology. With the momentum that SCA has, I expect that Microsoft will find a participation level that brings a balance to their efforts in the gamut of standards.
InfoQ: What is your role within the various OpenCSA technical committees?
MR: I am a co-chair of the SCA-J TC, and a member of 4 other SCA-related TCs. I am also a member of the steering committee that oversees the OpenCSA work.
DB: I'm serving on the OASIS OpenCSA Steering Committee and participating as an observer on the six Technical Committees.
SP: SAP is co-chairing the SCA-J TC and the SCA-BPEL TC. In addition, SAP intends to continue being an active technical contributor, and also volunteer for TC roles such as specification editor, etc.
InfoQ: Do you see SCA collaborating or influencing other standards activities elsewhere?
ME: Yes. There are a variety of other standards which relate to SCA. Some of those will influence SCA, others SCA may influence. An example are the standards involved in management of systems, since when an SCA application is managed. it will be most useful for the management interfaces to reflect the SCA strucuture of the applications.
DB: From our internal experience and customer interactions, we see good opportunities for collaboration or influence in the areas of deployment, security, and policy in the near term.
InfoQ: What do you hope will be the output from the OpenCSA Plenary?
SP: We hope to see a broader OASIS membership joining the SCA effort to validate and drive further the development and adoption of SCA technology.
DB: The most important outcome of the plenary and face-to-face meetings is to get all the TCs off to a great start and progressing on their respective charters. By having all six TCs start at this one event, they'll have a better sense of the interdependencies and coordination between TCs that will a factor in the success and adoption of SCA.
ME: The Open CSA plenary week will see the launch of the 6 SCA technical committees. The output of the week will set the pattern of the work on SCA for the next year or so. In addition, for those folk new to SCA, the plenary week will offer the opportunity for some great free education on SCA from experts who have been involved from the start.
MR: I am looking to quickly deal with procedural issues and then start constructing the list of meaningful technical issues that the TC members are already aware of with the input specifications. I'm hoping that these first days of meeting face-to-face will put us on a solid trajectory of effective technical progress that we will be able to maintain in the teleconference-based meetings that follow.