Hi, Here are my 2 cents for the SCA vs. ESB discussion:
1) IMO, SCA and ESB are positioned differently. SCA is an application oriented service construction and assembly model while ESB is about the integration of middleware to facilitate application connectivity. In a way, SCA defines the logical structure and composition of an application. With SCA, developers can focus on the business logic without being puzzled by plumbing technologies. I have tried a JBI based ESB. To my limited experience, the application code has to deal with the normalized message to extract the request and package the response, the business logic is polluted and coupled with the technology API calls. 2) ESB can be the communication infrastructure between SCA components. SCA uses declarative bindings to configure how services communicate over various protocols. In SCA, the reference and service need to have the same bindings so that they can be wired. ESB can provide a universal binding for SCA to hide the communication details. 3) ESB can also provide technology-oriented SCA components to support the mediations between business components, for example, routing, protocol conversion, data mapping, data transformation and business rules. There is also an interesting presentation from OASIS OpenCSA group: http://events.oasis-open.org/home/sites/events.oasis-open.org.home/files/SCA-ESB-v4.ppt Thanks, Raymond From: Moreau, Christopher Sent: Wednesday, February 18, 2009 3:57 PM To: [email protected] Subject: RE: General selling point question (more, different questions) My impression after considering the same type of questions is that Tuscany is functionally another type of ESB. Since there is no standard for ESBs (similar to the servlet standard for the app server) implementation and deployment of services and communication between them becomes specific to the stack you have committed to. The theoretical benefit of the "SCA ESB" is that you have a standard. The standard based deployment descriptor (the .composite file) is an example benefit. You have more flexibility in binding (multiple contributors can communicate with the different bindings) and implementation types. That being said, you have still committed to a particular stacks way of doing things, in this case it's the Tuscany SCA ESB way which has its own collection of annotations, syntax, messaging, and deployment methods. Based on my current work, I would love to see SCA as an obvious choice but what seems to complicate this choice even more is the various long standing bugs with, and/or limited implementation of what would seem to be very prominent binding types, namely web services, EJB, JMS: For example: WS Related Issues (note the summary listing for each TR is mine, not in the actual listing) TUSCANY-1758: Errors occur when referencing a WS created using Axis2 1.3 TUSCANY-1890: Conversations not support for components using WSDL interface TUSCANY-1892: WSDL Generation does not support methods that throw Exceptions TUSCANY-1912: Errors occur when promoting a reference that uses the WS binding and callback functionality TUSCANY-2059: WS binding does not support methods with no parameters and a void return type TUSCANY-2386: Errors occur when using the WS binding and arrays of XML bound objects TUSCANY-2664: Errors occur when using the WS binding and Axis2 objects TUSCANY-2757: Errors occur when using Tuscany generated WSDL containing nillable types TUSCANY-2853: Cannot create WS clients from Tuscany generated WSDLs Misc Issues TUSCANY-2215: Destroy method not called when request scoped components are destroyed TUSCANY-2824: WS binding does not apply the assigned WS security rules; full access is given to any caller WRT:>From my point of view SCA's role is to provide consistency. For example, consistency in the programming model used to expose services and exploit references to other services, Don't I get this as soon as I commit to any stack? WRT:> consistency in the way you describe the assembly of components in your solution Again, don't I get this as soon as a pick my ESB stack(e.g. service chains in Mule or JBoss, or BPEL w. JBoss) >and consistency in the way that policy is applied to control quality of service concerns. The SCA model applies regardless of what implementation or communcation technology youuse.I would like to understand this more so I can defend this. We're still experimenting with application of policy. For QoS, am I just applying a constraint? E.g.: It can answer within 3 seconds or I'm not interested. We're investigating use of policy for identification and authorization (w. SAML), any pointers or places in the wiki you recommend we look? >In you're scenario how do the multiple contributors implement services and communicate with the ESB? Do services only ever communicate via the ESB?The various contributors are experimenting with this right now. Service chaining is used, UDDI is use for look up, etc. With regard to the communication model and the SCA spec, we were very interested the default binding and the possibilities of that binding for providing interoperability between Java and C/C++ based components. The spec suggested the default binding might become a runtime discriminator on the basis of performance. This seemed very relevant. However Tuscany implements Java component support and C/C++ component support in separate runtimes and thus <I think> separate domains, so the communication between these implementation types is limited to a binding with high overhead (WS) which could be achieved in other frame works. In addition having the separate domains eliminates the possibility of using a very useful companion technology; SDO, between java and C++ components. Basically having separate runtimes for Java and C/C++ seems to tarnish the promise of supporting multiple implementation types. Was there a compelling reason for having separate runtimes? Please note that while my response my seem adversarial, I am only writing that way in order to hopefully get some great answers that I can learn from and use with others. Respectfully, Chris Moreau -------------------------------------------------------------------------------- From: Rich Smith Jr (rjsmith2) [mailto:[email protected]] Sent: Wednesday, February 18, 2009 1:47 PM To: [email protected] Subject: General selling point question (more, different questions) Sorry in advance for the noise if this is not the correct forum for this: Our group is currently negotiating with another group in our company to come to an agreement on a platform for some common services. The other team is pretty well set on EJB3 and JBoss, whereas we had been leaning toward SCA Java, in combination with at least Spring. Stangely enough, there seems to be quite a bit of convergence between the technologies, and I know that implementation.ejb is actually one of the SCA component implementation types. But, can anyone provide a pointer or some arguments in favor of or against Spring + Tuscany SCA Java ( + JBoss?) versus JBoss / EJB3. As a starting point, the EJB3 argument goes something like this: . JCP standards based . Rich set of application services bundled with app server . Built-in clustering capability (distributed coherent cache + JTA provided by app server) I think the Spring / SCA argument would include: . Supports heterogeneous components (EJB, Spring, OSGi...) . More configurable (lighter weight deployments possible other than full app server). The arguments against Spring / SCA include: . Requires assembly of more parts (SCA, Spring, JTOM, Hibernate, etc.) . No built-in clustering capability (Terracotta looked promising, but our legal department will never approve their license, and we don't want "Powered by Terracotta" all over our application, and we're too cheap to pay for it ;-) . Not JCP standard My take on the EJB3 case is that while clustering comes bundled, it is not clear that it would really buy us anything. For our app, we don't need load-balanced, symmetrical pools of service instances running across multiple JVMs. We actually need to carefully configure which services run where, which are colocated, and which have affinity to certain servers. (Maybe it is possible to configure this with JBoss? I know it is with Tuscany SCA Java.) Also, using EJB3 locks you into EJB-specific annotations, whereas using SCA with implementation.ejb, for example, would permit better interoperability with non-EJB components. Does anyone want to weigh in on this, or just provide some links? There's a lot of propaganda out there, and a lot of it is FUD or just plain out of date. It's hard to make a coherent argument one way or the other. Any help would be appreciated. Thanks. --Rich -------------------------------------------------------------------------------- From: Simon Laws [mailto:[email protected]] Sent: Sunday, February 15, 2009 6:43 AM To: [email protected] Subject: Re: General selling point question On Sat, Feb 14, 2009 at 5:51 AM, Moreau, Christopher <[email protected]> wrote: This isn't a specific technical question, but rather more of a how to I make the case for Tuscany SCA question. I am on a project with multiple contributors. The SOA has an ESB. I am having a hard time figuring out the key role for SCA. Many of capabilities seem like things available via the ESB. -C Hi Christopher. >From my point of view SCA's role is to provide consistency. For example, >consistency in the programming model used to expose services and exploit >references to other services, consistency in the way you describe the assembly >of components in your solution and consistency in the way that policy is >applied to control quality of service concerns. The SCA model applies >regardless of what implementation or communcation technology you use. In you're scenario how do the multiple contributors implement services and communicate with the ESB? Do services only ever communicate via the ESB? Regards Simon
