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>
<SAP>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.</SCA>
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>
<SAP> 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.
</SAP>
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>
<SAP>SAP is
an SCA developer</SAP >
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>
<SAP > 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.</SAP >
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>
<SAP> 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.
</SAP>
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>
<SAP> In addition, we hope to see a
broader OASIS membership joining the SCA effort to validate and
drive further the development and adoption of SCA
technology.</SAP>
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