Re: [service-orientated-architecture] McAlearney & Schulte on SCA & SDO

Sat, 05 Aug 2006 05:04:27 -0700

1- SCA has an application-centric perspective -- your goal is to build applications by consuming services. The end result of SCA is an application, not a service. BPEL [should] have a service-centric perspective -- your goal is to compose low-level services into higher-level services. The end result of BPEL is another service.

2- SCA is not limited to a single programming language or a single service-oriented middleware. Bindings are being defined for Java, C++, PHP, and BPEL. It supports services invoked via SOAP/WSDL, JMS, RMI, JCA, and JDBC. BPEL supports one programming language (BPEL) and one middleware (SOAP/WSDL).

Anne

On 8/4/06, Ron Schmelzer <[EMAIL PROTECTED]> wrote:

Steve:

Question for you. How does SCA differ from simply applying BPEL, or probably even better, WS-CDL, to compose Services and then letting each Service instance represented in its own container? What does SCA add to this picture? How does it help loose coupling? How does it differ from composition using metadata?

Ron

Steve Jones wrote:

We've used SCA a bit, and I have to say I like it.  Its going to be interesting how folks like SAP and Oracle link SCA (which IMO is good for developers) with JBI (which is aimed more at product to product) and whether this will be better than the SCA only route.
 
One bit I'm not sure about though was
"The third, Microsoft, does not support SCA, but
supports a similar concept in its new Windows Communication
Foundation&#9472;a part of the Vista and upcoming Longhorn server operating
systems."
 
SCA is a design, deploy, run, invoke framework based around the concept of containment (you do what you want inside the box), WCF is more code centric and aimed (IME) primarily at invocation rather than as a deployment container.  One of SCAs big plus points over WCF is this lifecycle rather than code centric approach.
 
Steve



 
On 01/08/06, Gervas Douglas <[EMAIL PROTECTED] > wrote:

<<Two specifications are helping developers navigate the stormy waters
of SOA implementation; Service Component Architecture (SCA) and
Service Data Objects (SDO) are two ways vendors hope to simplify the
process.

"SCA gives developers a new and better way to weave disparate SOA
services together into a SOA-style application. To a lesser extent,
it also helps with the creation of each individual SOA service
component," says Roy Schulte, Gartner's vice president of application
integration and middleware analysis. "SDO does for data in a SOA
application what SCA does for service components&#9472;it abstracts the
developer's view of the data in an effort to simplify the design and
maintenance of data-handling application functions."

The SCA and SDO specifications can simplify the creation of new
architecture and transform existing IT assets, enabling reusable
services to meet changing business requirements. These specifications
reduce complexity associated with developing apps by unifying services
regardless of programming language and deployment platform.

However, Schulte cautions that SCA is incomplete and immature.
"Companies should understand what it does and evaluate it for possible
future inclusion in their SOA strategy, as part of their standard
methodology for developing SOA applications," he suggests. "Those who
understand what is in SCA will have a good understanding of what is
missing in today's SOA development tools. By mid 2007, SCA will
probably be polished enough to provide tangible benefits to leading
edge companies developing SOA applications."

According to Schulte, two of the three major app vendors (SAP and
Oracle) support SCA. The third, Microsoft, does not support SCA, but
supports a similar concept in its new Windows Communication
Foundation&#9472;a part of the Vista and upcoming Longhorn server operating
systems.

In a March report, Gartner Research VP Jess Thompson, wrote, "One of
the most important aspects of SCA is that it establishes a foundation
for a standard notation for expressing a standard set of concepts for
specifying service-oriented architecture."

Before SCA, developers could build SOA apps in Java and other
languages, but had to use relatively low-level programming interfaces
to connect the service consumers and service provider components to
each other, Schulte says. And because there was no systematic way to
represent the relationships between the components, configuring and
maintaining large SOA apps with many components was complex.

"Essentially, SCA provides a new, metadata-centric way of designing a
SOA application at a higher level of abstraction, which should make
SOA applications easier to build, maintain and change," says Schulte.
"It helps that SCA supports multiple different programming languages
and its run time implementations will run on different application
servers and different operating systems."

Vendors initially came together to work on such specifications in late
2005. BEA Systems, IBM, IONA, Oracle, SAP AG, Sybase, Xcalia, Zend,
Cape Clear, Interface21, Primeton Technologies, Progress Software, Red
Hat, Rogue Wave Software, Software AG, Sun Microsystems and TIBCO
Software are the seventeen organizations involved&#9472;and what Gartner
calls most of the major players. Together, they have developed SCA and
SDO technologies, including new and updated draft specifications.>>

You can read this at:

http://www.adtmag.com/article.aspx?id=18990

Gervas




__________ NOD32 1.1689 (20060802) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

-- 
_____________________________________________________________
Ronald Schmelzer
[EMAIL PROTECTED]

Senior Analyst
ZapThink LLC
Direct: 781-577-2779 / Main: 781-207-0203

__._,_.___


SPONSORED LINKS
Computer software Computer security software Computer software program
Computer fax software Computer virus software

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to