>> I could not differentiate anything in there from generic SOA + BPM.
> The distinction is significant. Jeff, I'm the first to welcome a way to package and deploy these things we call services. However, the goals of the overview document clearly do not differentiate SOA+BPM from SCA in the least. Perhaps there's more there in one of these implementations, but how would anyone know that unless they take the time to implement one of the SCA reference implementations. Second, I mean this only as constructive criticism because I can see this is important to you, your answer comes across as one who is zealous rather than providing concrete information that the group can use to identify these differences. This is from the key white paper: 1. Application logic is divided up into application components that implement business services - this is what a service is to me. 2. Components have business-oriented, service-oriented interfaces. Components do not have interfaces that reflect middleware abstractions; they have interfaces that reflect business abstractions Again, this is what a service is to me. 3. Application components can be reused by "wiring" together new and existing application components to create new solutions. This assembly capability of SCA can integrate existing and new assets based on multiple heterogeneous technologies into a composite service network. This is BPM with BPEL to me. 4. SCA implements a separation between the concerns of a component implementer and the concerns of a system assembler creating a solution by wiring together existing components and services. Again, this is BPM with BPEL to me. 5. SCA can be implemented on top of a broad range of middleware environments Umm, Web Services? 6. Components are described and used in the same way regardless of the language or technologies used to implement the component. Umm, WSDL? (not that I think WSDL is the be-all-end-all of descriptions, but it certainly meets this criteria). 7. SCA allows "qualities of service" such as transactions, security and reliable asynchronous invocation to be applied to components declaratively and dynamically without requiring programming using complex API calls. Service Component Architecture Whitepaper 16 November 2005 A required addition to make SOA real, however, it belongs in the service contract and not in an orthogonal representation. 8. Irrespective of whether a component is local to the deployment unit or remote, the component is accessed through its defined business interface. SCA provides for assembly of components at multiple levels, allowing greater control and visibility of application artifacts. Expose a BPEL execution as a service? 9. A variety of resources such as Web services, EIS functions, remote EJBs can be modeled as remote components, and can generally be used without regard to the underlying implementation technology or of the transport. Some transports impose limitations on the qualities of service that can be supported. Again, Web Services takes care of this for me. 10. SCA supports multiple technologies for expressing the interfaces of components, including WSDL and Java interfaces. This is interesting, but perhaps misplaced. This has nothing to do with SOA, but everything to do with implementation. So, since this is the only real differentiator so far, I'd have to agree with Anne, SCA is all about consumption and exposing implementations as services. Perhaps SCA isn't the generic binder you'd like it to be, but it does sound like the next incarnation of Apache Axis. 11. Components with business service interfaces are used to provide access to data - separating issues related to data persistence from the business logic. This also facilitates portability of components between different runtimes. I do this today through architecture, it has nothing to do with requiring overhead of a wrapping scheme. 12. Infrastructure capabilities, such as Security and Transactions, are applied to component interactions rather than being accessed through code. This helps keep the business logic code clear of infrastructure concerns. Again, these should be added on the contract based on WS-AtomicTransactions and WS-Policy 13. Application components can be "customized" either at development time or at run-time, by delegating decisions to other components using the "strategy pattern"[18]. BPM/BPEL. 14. SCA defines an abstract model for implementing components and for accessing components. The model supports multiple concrete implementations in a wide variety of programming languages and technologies, including Java, C++, BPEL and XSLT scripts. SCA attempts to be "minimally intrusive" with few APIs and, where supported, uses techniques such as dependency injection to eliminate the use of APIs altogether. So does Web Services. 15. The preferred form for data exchanged between components via remotable business interfaces is that defined by the Service Data Objects (SDO) specification [2]. I have to admit I don't get the need for SDO at all. My services represent my Model (as in model/view/controller) and all my data is represented as business objects. This is an architectural constraint to me and not an implementation specific issue. > The concept of the assembly is a concept that is leaning toward > something that would lead to greater componentization of service > groups if done right, but it's nowhere now. Why do you say nowhere? There is product support for it today. I agree with Mark Fleury here that this is a proprietary implementation scheme for Websphere et. al. > I had a talk with John Evdemon yesterday (co-Chair of BPEL TC) and >V2.0 of BPEL isn't due until May and not all participants are > buying into IBM's proprietary extensions for human workflow and >executable linking. Additionally, BPEL won't support sub-processes, > so if Tuscany is based on BPEL as the glue, this things a long way > from reality. -SCA has absolutely no reliance on BPEL. It is one of many potential -Domain Specfic Languages that can be bound to SCA. What other industry standard is available for wiring? Yahoo! Groups Links ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income homes are not online. Make a difference this holiday season! http://us.click.yahoo.com/5UeCyC/BWHMAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> 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/
