Vendors deliver Service Component Architecture and SDO specs

Discussions

News: Vendors deliver Service Component Architecture and SDO specs

  1. A series of vendors have delivered the Service Component Architecture (SCA) and Service Data Objects (SDO) specifications to help developers construct service oriented architectural solutions. SCA is a composition model for business services and SDO is a common rendering methodology for data exchange between clients and services.

    According to the specifications page:
    SCA provides an open, technology-neutral model for implementing IT services that are defined in terms of a business function and make middleware functions more accessible to the application developer. SCA also provides a model for the assembly of business solutions from collections of individual services, with control over aspects of the solution such as access methods and security. Vendors working to create SCA include BEA Systems, IBM, IONA, Oracle, SAP, Siebel, and Sybase.

    SDO complements SCA by providing a common way to access many different kinds of data. The specification reduces the skill levels and time required to access and manipulate business data. Today, a multitude of APIs are used to manipulate data. These APIs tend to tightly couple the source and target of the data making their use error-prone and subject to breaking as business requirements evolve. SDO makes it easier to use and realize the value of these APIs without having to code directly to them. Vendors working to create SDO include BEA Systems, IBM, Oracle, SAP, Siebel, Sybase, and Xcalia.
    The SCA specification is at revision 0.9. The SDO specification has been discussed on TSS already, and the current revision of that specification is 2.01.

    Both specifications are available royalty-free, and the authors are soliciting feedback.

    See also: Tech giants get behind new SOA programming model

    Threaded Messages (40)

  2. Specs and articles can also be found on the other participants' sites. BEA's are at (I will leave it to others to post their respective links):

    http://dev2dev.bea.com/pub/a/2005/11/sca.html

    For those interested, some BEAers have also blogged about SCA:

    http://dev2dev.bea.com/blog/wgroth2/archive/2005/11/sca_and_the_fut.html

    http://aporiae.blogspot.com/

    Hopefully some of the other SCA participants will also post blogs. Since this has been a cooperative effort, I should also point out that an interesting related article has also been written by IBMers involved in the specifications:
     
    http://www-128.ibm.com/developerworks/webservices/library/ws-soa-progmodel6/

    Jim Marino
    BEA Systems
  3. For the Oracle friendlies, the specs are here:

    http://www.oracle.com/technology/tech/webservices/standards/sca/index.html

    Mike Lehmann
    Oracle
  4. Where are the implementations?[ Go to top ]

    SDO look pretty nice and solve a nagging problem but where are the implementations? Only IBM has EMF and it does not match the spec. EAttribute, E... stuff that make your eye bleed when you read it.

    When is BEA or other vendors coming up with more compliant implementation? Please spare us the 'Coming soon'. Thanks!
  5. Where are the implementations?[ Go to top ]

    SDO look pretty nice and solve a nagging problem but where are the implementations? Only IBM has EMF and it does not match the spec. EAttribute, E... stuff that make your eye bleed when you read it.When is BEA or other vendors coming up with more compliant implementation? Please spare us the 'Coming soon'. Thanks!

    See http://marc.theaimsgroup.com/?t=113337453000005&r=1&w=2

    James
    LogicBlaze
  6. Re:Where are the implementations?[ Go to top ]

    SDO look pretty nice and solve a nagging problem but where are the implementations? Only IBM has EMF and it does not match the spec. EAttribute, E... stuff that make your eye bleed when you read it.When is BEA or other vendors coming up with more compliant implementation? Please spare us the 'Coming soon'. Thanks!

    Check out IBM's WebSphere Process Server (and associated Eclipse-based toolset WebSphere Integration Developer) released in late September 2005 for currently available implementation of slightly earlier versions of SCA and SDO:

       http://www-306.ibm.com/software/integration/wps/
       http://www-306.ibm.com/software/integration/wid/

    Cheers,
    Pranta
  7. Executive summary[ Go to top ]

    My cynical summary (before actually reading the specs of course): it's gonna be the next failed component model after EJB and it will make it possible to write a whole new generation of applications that fetch stock quotes from the web with only 27 layers of abstraction :-) It's also *wonderfullly* complementary to the 59 existing WS-* and XML-* specs, all of which are necessary.
  8. Executive summary[ Go to top ]

    Hopefully we will have less than 27 layers of abstraction ;-) For example, the account service mentioned in a previous post could be implemented in Java simply as:


    public class AccountServiceImpl implements AccountService {

        private String currency;
        
        public void setCurrency(String currency){
            this.currency = currency;
        }
        
        public float getBalance(){
            // return the balance
        }

    }


    The previous XML metadata would expose the above service over a web service binding. Also, while SCA could use WS-* and various XML binding technologies, they are not necessary. I could have chosen to expose the service over some other protocol that does not use web service or XML binding technologies.

    Jim Marino
    BEA Systems
  9. that include all the WS-I specs?[ Go to top ]

    the number seems a bit low if you also count the WS-I stuff.

    :)

    peter
  10. Executive summary[ Go to top ]

    It looks like you are right, this idea sounds good and every attemtp looks promissing but component models do not live very long for some reason.
  11. More info on the SCA[ Go to top ]

    I have written more about the SCA announcment here, and you can also read more info at the BEA SCA Resource Center.
  12. SCA Link[ Go to top ]

    Here is a current article series on SCA:

    http://www-128.ibm.com/developerworks/websphere/techjournal/0510_brent/0510_brent.html
  13. Any open implementations?[ Go to top ]

    I have read the SDO and SCA specifications. I hope that both specs will gain acceptance in the development community. I definitely see the value in SDO's data source independent approach and I really like SCA's component model.

    I am aware of the Eclipse implementation of SDO on top of thier EMF framework.

    Does anybody know of any other open implementations of SDO and/or SCA?
  14. Any open implementations?[ Go to top ]

    Yes, stay tuned as several industry partners plan to an open source proposal regarding both a Java-based SCA runtime and SDO implementation.

    Jim Marino
    BEA Systems
  15. Where does JBI fit into this new SOA movement?

    SCA sounds like another superset of CORBA for integration. People complained about IDL's. Looks like they're gonna luv sca assembly defs.

    This whole spec(SCA) looks surprisingly close to Corba Component Model(CCM) specification:

    http://www.omg.org/docs/ptc/02-08-03.pdf
  16. I'll address only the JBI question. JBI provides SPIs that allow people to plug in their own "service engines" and "binding components". It is very much targetted toward the middleware vendor as its audience.

    SCA, as it exists now, targets application developers, assemblers (who are often also the developers) and deployers.

    However, SCA needs to be able to support multiple development languages and technologies. This implies that there will eventually need to be SPI standards for the various extension points. In the Java world, JBI would be one possibility that we would probably want to support for providing these kinds of extensions.

    Michael Rowley
    BEA
  17. I'll address only the JBI question. JBI provides SPIs that allow people to plug in their own "service engines" and "binding components". It is very much targetted toward the middleware vendor as its audience.SCA, as it exists now, targets application developers, assemblers (who are often also the developers) and deployers.

    Agreed. I think thats the big difference; SCA is focussed at application developers programming model to help them develop and work with services. JBI is focussed on building an ESB with pluggable integration components, so its more focussed on the middleware providers than application programmers. However I think the two can work very nicely together.

    I really like SCA - it looks a great model for developing services using POJOs and annotations. I particularly like the conversational service support and the fact that SCA can work with SDO or with JAXB 2 as the marshalling layer. (It might be nice to allow services to work directly with an XML Source too, or a JBI NormalizedMessage ;-)

    On the ServiceMix project lately we've been integrating various different application developer programming models into the JBI service bus - Spring, SAAJ, JAX-WS, JSR181, JCA and so forth; we're looking forward to integrating Tuscany into ServiceMix so that SCA developers can choose to deploy in a JBI container if they wish and make use of the smart routing, transformation and orchestration features of an ESB.

    James
    LogicBlaze
  18. Yes, many of us were familiar with CCM but SCA is quite a bit different than CORBA. One of the interesting things, though, is that it contains an early form of IoC/Dependency Injection (ATG Dynamo also implemented this back around the same time as well, if not before).

    In any event, one thing we specifically wanted to avoid with SCA is the introduction of yet another lingua franca for describing service interfaces - that's why we left it up to the protocol bindings and SCA runtimes to do so (e.g. one can use WSDL, straight Java, etc. with the limitations such choices imply).

    On the complexity of assembly definitions, we purposely tried to keep the XML simple. Most of us on the spec group prefer a minimum of tooling. The following example exposes a java-based service over a web service binding:


    <?xml version="1.0" encoding="ASCII"?>
    <module xmlns="http://www.osoa.org/xmlns/sca/0.9" xmlns:v="http://www.osoa.org/xmlns/sca/values/0.9" name="account">
        <entryPoint name="AccountService">
            <interface.java interface="com.foo.AccountService"/>
            <binding.ws port="http://www.bigbank.com/AccountService/#AccountServiceSOAP"/>
            <reference>AccountServiceComponent</reference>
        </entryPoint>

        <component name="AccountServiceComponent">
            <implementation.java class="com.foo.AccountServiceImpl"/>
            <properties>
                <v:currency>EURO</v:currency>
            </properties>
        </component>
    </module>


    Entry points are used to expose services offered by components over a binding. For example, another entry point could be added that exposes the same service over a JMS or RMI binding.

    The above could be rendered in a terser format if validation is not required (SCA provides schemas to do so).

    Regards,

    Jim Marino
    BEA Systems
  19. What about JBI? Corba Component Model(CCM)[ Go to top ]

    Before SCA and SDO came there was WSIF(web services invocation framework) whic allowed the program to look at JavaBean, EJB and SOAP all as web services. It made sense. SCA and SDO are trying to achieve the same thing.
    SDO it totally bullshit. Why on earth i would want my business classes to inherit from any class(DataObject) to make in non-portable abd vendor dependent. Whats wrong with JDO which can transperently persist POJO.

    While whole world is going toward dependency injection, SDO is trying to bring you back to inheritence and tight coupling/dependency model.
  20. SDO vs JDO[ Go to top ]

    Just for your information Robin Roos did nice comparison

    Comparing SDO (JSR-235) to Detachment in JDO 2.0 (JSR-243)
    http://www.jdocentral.com/jdo_commentary_robinroos_6.html

    He came to the following conclusion:
    "...
     Both SDO and JDO detachment appear to have a place in enterprise architectures. Designers looking for disconnected access to persistent data will have to choose between them, but they actually occupy separate niches, as I will now describe.

    With JDO detachment, the domain object model (or a segment thereof) is the data transfer object. This has advantages such as there being no need to define and populate analogous but distinct DTO classes, and the ability to execute domain-resident logic directly on the client tier.
    ..."
  21. SCA / SDO coupling (or lack thereof)[ Go to top ]

    Before SCA and SDO came there was WSIF [...] SCA and SDO are trying to achieve the same thing.

    It's worth noting that the SCA spec doesn't really have any particular strong coupling to SDO. Also, FWIW, SDO is much more about APIs for disconnected data access than about things like O/R mapping or object lifecycle etc. You could even imagine creating an SDO Mediator^H^H^H^H^H^H^H^H DSP (Data Service Platform?) that uses JDO (or even EJB3 JPA) behind-the-scenes.

    -Patrick

    --
    Patrick Linskey
    http://bea.com
  22. SDO DSP based on JDO[ Go to top ]

    You could even imagine creating an SDO Mediator DSP (Data Service Platform?) that uses JDO behind-the-scenes.

    Not on ly you can imagine it Patrick but it already exists, it is XIC from Xcalia.
    Best Regards, Eric.
  23. JDO / SDO[ Go to top ]

    IMHO it would be a mistake to oppose JDO and SDO (as it has been done sometimes).
    Both are complementary and address different needs.

    JDO 2 / EJB 3 are nice when you have complete business models well defined at development time. POJO are very important in complex business applications.

    SDO is nice when you have to deal at the data level, and you don't have business logic, that is the case in many situations (simple data management applications, reporting...).

    A JDO product like XIC from Xcalia can send information to other tiers through detached POJOS or through DataGraph of DataObjects.

    I strongly believe that both approaches will co-exist.

    Best Regards, Eric (Xcalia).
  24. An SDO compliant product[ Go to top ]

    Does anybody know of any other open implementations of SDO and/or SCA?

    Xcalia Intermdediation Core is compliant with SDO 1.0 since beginning of 2005. We are working on 2.0 compliance. The product is not based on EMF.

    Best Regards, Eric.
  25. JavaEE and SCO[ Go to top ]

    Will SCO ever make into JEE? Is there a JSR for this to be created?

    BTW, SDO fits the picture now (after introduction of SCO) as a standard data manipulation (transfer objects) API
  26. A turn over for J2EE without Sun?[ Go to top ]

    Is it the new way of working here?
    SDO is not even a standard at the moment. I am afraid we will see products from IBM, BEA and Oracle supporting this specs even before the specs are approved as a standard.
    That's a major change compared to the JCP way of working which was maybe slow but more democratic.

    Let's think a minute about this, for web services clients, SDO is another way of working compared to JAXB and JAX-WS. What is about to happen now? J2EE 5 will say you must use JAXB and JAX-WS and IBM will say: "you're kidding, just use SDO"?
    Applications built using SDO will not run on JBoss, not even on the Sun J2EE reference implementation?

    The reality is that there is no more one standard umbrella for Java Enterprise Edition stuff or maybe just Enterprise Edition stuff because all this is language independant.

    This is a tactical move, something that has been created to return the control to a limited set of vendors. That's it.
    I've been blogging about this before http://blogs.ittoolbox.com/eai/applications/archives/006747.asp
    Think about it.

    The spec itself could be good or not compared to what we have already, the result is that it is likely that IBM, BEA,... will grow their application server market share.

    Hé Marc, what will JBoss do?
  27. A turn over for J2EE without Sun?[ Go to top ]

    Let's think a minute about this, for web services clients, SDO is another way of working compared to JAXB and JAX-WS.
    That's likely too simplistic a comparison. When I was using service data in Globus, it could be queried, monitored, and refreshed with ease. It's a natural fit for making a global registry, especially for indexing replicas. Eg loadbalancing, each service instance's load could be a service datum, tracked in a global (or distributed) index, so a client could easily look up the least loaded servant.
    What is about to happen now?
    I totally digged Bill Roth's blog entry. Very lucid for an executive summary. So I agree with him that SCA/SDO is the future of SOA, especially for grid and utility computing.
  28. I really like the SDO specs. I haven't checked the other one yet but I don't like the way to approve it outside of the JSR. There hasn't been any new info on the official SDO specs (JSR 235) since a long time. Seems like a kind of polical move, I guess I won't use it until it changes, even if my organisation is using Oracle app. server.
  29. IMO it would be great for the entire Java community if ONE undisputed SDO spec would emerge.
    It is a great way to lously couple different systems and layers. Hence it should be possible for tool builders to use SDO as a source to rappidly build (parts of) a system. For example Gui builders, MDA tools, unit/integration test tools, BPEL tools etc.
  30. How does it relate?[ Go to top ]

    How does SCA relate to EJB3 and / or JSR-181 annotations? These almost seem like annotation-based configurations for JBI service assemblies.... Seems like SCA has a lot of overlap with other technologies, and these relationships need to be clarified.
  31. How does it relate?[ Go to top ]

    SCA and EJB3 persistence should play very nicely together (e.g. the ability to inject an EntityManager on a component implementation). Also one of the most important goals of SCA assembly is to support a variety of programming models. For example, it will be possible to assemble a service network consisting of implementations using a variety of technologies such as Spring, EJB3 simplified, JAX-WS/JSR-181. This will allow users to wire together Spring, J2EE (EJB) applications, SCA POJOs, etc.

    In a similar way, SCA does not dictate the presentation tier although we have thought about how it integrates there as well. For example, SCA local services may be scoped and can be mapped to things such as MVC action classes, JSF backing beans, etc., to allow injection at that tier as well. The BigBank sample app has some examples of this in rudimentary form.

    Jim Marino
    BEA Systems
  32. How does it relate?[ Go to top ]

    :-) You just answered with an "it can do anything and everything"... I still don't know how I'd USE it... I mean, I can already have Spring-managed beans that can have JSR-181 annotations, transactional annotations, mapping to an MVC front end with dependency injection, etc. so what's the advantage here? Is this more of an alternative to Spring with some web services and other remoting support built in?
    SCA and EJB3 persistence should play very nicely together (e.g. the ability to inject an EntityManager on a component implementation). Also one of the most important goals of SCA assembly is to support a variety of programming models. For example, it will be possible to assemble a service network consisting of implementations using a variety of technologies such as Spring, EJB3 simplified, JAX-WS/JSR-181. This will allow users to wire together Spring, J2EE (EJB) applications, SCA POJOs, etc. In a similar way, SCA does not dictate the presentation tier although we have thought about how it integrates there as well. For example, SCA local services may be scoped and can be mapped to things such as MVC action classes, JSF backing beans, etc., to allow injection at that tier as well. The BigBank sample app has some examples of this in rudimentary form. Jim MarinoBEA Systems
  33. How does it relate?[ Go to top ]

    Along these lines, This mail by Geir Magnusson is pretty funny...
    :-) You just answered with an "it can do anything and everything"... I still don't know how I'd USE it... I mean, I can already have Spring-managed beans that can have JSR-181 annotations, transactional annotations, mapping to an MVC front end with dependency injection, etc. so what's the advantage here? Is this more of an alternative to Spring with some web services and other remoting support built in?
  34. How does it relate?[ Go to top ]

    ... I still don't know how I'd USE it... I mean, I can already have Spring-managed beans that can have JSR-181 annotations, transactional annotations, mapping to an MVC front end with dependency injection, etc. so what's the advantage here?

    Two that are important in the SOA space:
    - An abstraction for wiring together services, independent of how those services are implemented (not tightly coupled to a single language or platform)
    - implementations available from multiple vendors
  35. How does it relate?[ Go to top ]

    OK I'll try to be a little more specific; here are some things it offers:

    - Language-independent assembly - services can be implemented using Java POJOs, C++, BPEL, XSLT, whatever the runtime supports. Basically, assembly provides a language-neutral representation of a service *network* (whereas WSDL describes a service).

    - SCA provides for wiring and injection ("assembly") not just at a local level (inside a module) but also across remote boundaries (non shared memory) as well. I'm unaware of an existing technology that does this. For example, it is possible to wire together services in different runtime instances. This allows for runtime environments that can extend from "programming in the small" to "programming in the large". SCA provides a way to express service network architecture (design), service construction (development), and runtime "management" (late-bound wiring of services, monitoring, etc.) and have those stay in sync. For example, from a bottom-up approach, a developer could author a bunch of services (stubbing some out for testing), bundle them up as a module, have them wired to live services with QoS applied when they are deployed, and then monitor them. From a top-down approach, an architect could define service contracts (WSDL, Java, etc.), service dependencies, and base qualities of service and give those artifacts to developers to implement. Those same artifacts would then be used for deployment and runtime monitoring.
     
    - SCA provides unified support for asynchronous communications, conversations, and other stateful services that may be local or remote.

    - Clear semantics for local and remote services

    - Policy (security, transactions) and QoS support in a way that abstracts as much as possible from underlying transports. We still need to do quite a bit of work here but this in one of the areas we see SCA adding important value.

    We do not see this as an alternative to Spring. Rather one of the goals will be to support Spring as a first-class citizen in assembly. Hope this helps somewhat.

    Regards,
    Jim Marino
    BEA Systems
  36. How does it relate?[ Go to top ]

    Thank u Jim for the explanation.
    It does look great !
    Any chance for BEA to support SCA and JBI in the Aqualogic ESB solution ?

    Rgds-Claude
  37. How does it relate?[ Go to top ]

    Hi Claude,

    As Mike mentioned in a previous post, we are looking at JBI as one possible way to extend SCA. James also pointed out a number of interesting possibilities related to ServiceMix that we will definitely explore in the context of open source. I can't comment on our (BEA) specific product plans at this point (I also want to keep this focused on technology as opposed to pushing product) but I can say that one of the things we want to accomplish with SCA assembly is to make the notion of service composition more concrete.

    I'm sure each of the vendors participating in SCA will have a lot more to say regarding product plans moving forward.

    In the meantime, you may want to follow the open source discussions regarding Tuscany (linked in a previous post) and maybe even get involved as we are looking to open source as an avenue for evolving the specifications.

    Regards,
    Jim
  38. It seems to me a nice evolution of the service model in SOA.

    Even if SCA does take advantage of many aspect of Web-Services it seems to me that the SCA specification recognizes that Web-Service is not the only way to implement a SOA.

    Hoping that the new specification will help to simplify the usage of the ws-* by putting them in a set of aspect (For example transaction aspect,security aspect,asynchronous aspect)and then those aspects can be bind to the SCA.

    Currently the number of ws-* for dealing with
    asynchronous,transaction,security are quite overwhelming !

    I am sure the above should sound familiar to the EJB 3 folks !

    Rgds-Claude
  39. Even if SCA does take advantage of many aspect of Web-Services it seems to me that the SCA specification recognizes that Web-Service is not the only way to implement a SOA.
  40. Even if SCA does take advantage of many aspect of Web-Services it seems to me that the SCA specification recognizes that Web-Service is not the only way to implement a SOA.

    Web services has never been the only way to implement a SOA.
    I am wondering what kind of SOA would you could build if the messages you pass between service consumers and providers are not described in XML? This SOA might allow you to do some remoting but never to integrate with other kind of technologies like Microsoft clients or legacy back-ends that do not understand SDO datagraphs at all.

    I have the feeling that SDO is more to be used in the implementation of a service. Between the service implementation and its underlying resources when there is few business logic in this service and that an elaborated domain model supporting that logic is not necessary.
  41. SCA simplifying the use of WS-*[ Go to top ]

    The SCA specification does aim to simplify the usage of the various WS-* specifications. Appendix 2 of the SCA Assembly specification describes the SCA model for dealing with the often complex infrastructure capabilities such as Security and Transactions.

    The idea is first to separate the definition of these capabilities from the service components and the wires connecting the components. Second these capabilities can be offered to the programmer and/or system assembler as high-level policies, used by name and with a few simple settable attributes.

    The Policies in turn point to more detailed configurations (which would be drawn up by experts in the field) which allow more detailed control of the capabilities, if required.

    The whole idea is to get the amount of understanding required by the average programmer down to something small and simple, while not giving up necessary control of vital aspects of a solution.


    Yours, Mike
    IBM.