On 5 Sep 2007, at 14:11, Mike Edwards wrote:
Folks,
My
input as
<mje>...</mje>
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
IBM Hursley
Park, Mail Point 146, Winchester, SO21
2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
Here are the questions for the InfoQ interview. Please feel free to answer any
and all. If you do answer any question, please put your full name and position within
your company and role within SCA/OpenCSA at the start of any reply: that way I
can link the information into the finished article. Please send answers to me
directly and then I'll follow up on a one-on-one basis if necessary.
Thanks,
Mark.
Q: Why do you think it has taken so long for SCA to get to a standards body?
<mje>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.</mje>
Q: Why OASIS and not W3C?
<mje>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.</mje>
Q: Why is SCA-J not being worked on within the JCP?
<mje>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.</mje>
Q: If you had to summarize what SCA brings to this space in two sentences, what
would they be?
<mje>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.</mje>
<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.</MR>
Q: Why is your company interested in SCA?
<mje>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.</mje>
<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.</MR>
Q: Do you see any overlap between SCA and JBI?
<mje>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.</mje>
<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. </MR>
Q: Is there an equivalent of SCA within Microsoft's arsenal of SOA technologies?
<mje>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.</mje>
Q: 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?
<mje>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.</mje>
<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 technolgy.</MR>
Q: 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?
<mje>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 very
much part of the world of SOA.</mje>
<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.</MR>
Q: 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?
<mje>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.</mje>
<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.</MR>
Q: Is you company an SCA developer, user, or both?
<mje>Both. IBM builds
products that provide SCA, but IBM also has a services arm that builds
solutions using SOA
for our customers.</mje>
<MR>BEA
is an SCA developer.</MR>
Q: Where do you see SCA fitting within your company's SOA strategy?
<mje>It is an important
aspect of the core products that support building SOA applications.</mje>
<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.</MR>
Q: 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?
<mje>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.</mje>
Q: What is your role within the various OpenCSA technical committees?
<mje>Is this meant to be a personal
question or a company question????...</mje>
<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.</MR>
Q: Do you see SCA collaborating or influencing other standards activities
elsewhere?
<mje>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.</mje>
Q: The OpenCSA Plenary week is coming soon. What do you hope will be the output
from that series of meetings?
<mje>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.</mje>
<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.</MR>
Michael
Rowley
BEA Systems, Inc.
----
Mark Little
mlittle@redhat.com
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire,
SI4 1TE, United Kingdom.
Registered in UK and Wales
under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA)
and David Owens (Ireland)
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England
and Wales
with number 741598.
Registered office: PO Box 41,
North Harbour, Portsmouth, Hampshire PO6 3AU