[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [opencsa-ms] Interview reminder
|
Hi Mark, I’ve added my replies inline with
Mike Edwards and Michael Rowley with <db> … </db>. Regards, David Q: Why do you think it has taken so long for SCA to
get to a standards body? <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.</db>
<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.</db>
<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.
<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> <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.</db>
<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> <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.</db>
<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 <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.</db>
<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> <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.</db>
<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> <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. </db>
<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>
<MR>BEA
is an SCA developer.</MR> <db>TIBCO
is an SCA developer, providing products that our customers can use to build SOA
based solutions</db>
<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> <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.</db>
<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.
</db>
<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> <db>I’m
serving on the OASIS OpenCSA Steering Committee and participating as an
observer on the six Technical Committees</db>
<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. </db>
<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> <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.</db>
From: Mark Little
[mailto:mlittle@redhat.com] Just a reminder to please send me your interview text for Infoq by the
end of this week. So far it looks like we won't have enough respondents to make
this happen. Mark. ---- Mark Little JBoss, a Division of
Red Hat Registered Address:
Red Hat UK Ltd, SI4 1TE, Registered in Directors: Michael
Cunningham (
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]