I also think partially it has to do with the concerns you're trying to address. From an architectural perspective, you want to be able to orchestrate services (via BPEL or whatever) and not have to worry about where and how they're built and deployed. This is the perspective that enables the business.
However, the thing that SCA and others (JBI, Spring, etc.) give you is the ability to look at the implementation perspective in a coherent manner. If you're trying to scale one service or have determined by measurement or observation that two services are sending a large number of messages to each other, it makes sense to co-locate those services into the same container--possibly bypassing the network hop altogether. This is the perspective that allows you to make deployment decisions to enable the architecture. Based on what I've seen first-hand though, it is difficult to keep these two views separate while at the same time developing services based on the business architectural view instead of the deployment view. What I mean by this is that if you concentrate on the enabling capabilities of the framework or container, then you may introduce dependencies between services that will introduce operational issues as the architecture evolves and needs to leverage temporal and spatial loose coupling. Regardless of the framework used, the services should be implemented as if they are the only one using it and let the where and how they are deployed be based on the needs of the architecture rather than decisions forced or influenced by the framework. On Sat, 2006-08-05 at 12:18, Anne Thomas Manes wrote: > 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─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─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─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─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 > > > > > -- Andrew S. Townley <[EMAIL PROTECTED]> http://atownley.org Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
