Home

News: Apache Tuscany M1 released

Bookmark and Share Get thread feed

  1. Apache Tuscany M1 released (8 messages)

    The Apache Tuscany community has announced its first milestone release, Apache Tuscany/Java M1. Tuscany is an effort undergoing incubation at the Apache Software Foundation (ASF), providing a Java implementation of the Service Component Architecture (SCA) and Service Data Objects (SDO) specifications, and a Data Access Service (DAS) supporting SDO. Pointers to the SCA, DAS, and SDO specifications are available from the Tuscany site. Binary and source distributions are available from the site as well. SCA Implementation - Key Features
    • General framework for wiring SCA components together and running them
    • Module assembly using SCDL (SCA 0.9 spec level)
    • Support for synchronous and asynchronous (one-way non-blocking) invocations
    • SCA scope management
    • Extensibility APIs, new bindings and component types can be easily plugged in
    • Bootstrapping APIs
    • Plugins/extensions:
      • Support for POJO components and SCA Java 5 annotations
      • Support for Javascript components
      • Axis2 Web Service binding
      • Celtix binding
      • JSON-RPC binding
      • SDO data binding
    • Hosting in J2SE and Tomcat (SCA modules deployed as Web applications)
    • WSDL2Java tool and experimental Java2WSDL tool
    • Example programs showing components, wiring, and integration of bindings
    • Implementation of the Bigbank sample application published with the SCA spec
    SDO Implementation - Key Features
    • Dynamic data object support (SDO 2.0.1 spec level)
    • Basic static code generation (generator patterns still subject to change)
    • Helper classes partially/fully implemented (XMLHelper, DataFactory, etc.)
    • ChangeSummary support in DataGraph (no ChangeSummary attributes)
    • Some simple example programs
    DAS Implementation - Key Features
    • RDB CRUD operations in terms of SDO DataObjects
    • Optimistic concurrency control
    • Generated database IDs
    • Stored procedures
    • Paging API
    • 1..1 and 1..n relationships
    • Partial row updates
    Reply to this

    Threaded Messages (8)

  2. Re: Apache Tuscany M1 released[ Go to top ]

    I'd like to be the first to congratulate the guys from BEA and IBM on a very good start. I expect Tuscany to become the reference implementation for SDO/SCA. Can I suggest that you need to sign up some more contributors? PJ Murray, CodeFutures Software Data Access Objects and Service Data Objects
    Reply to this Reply to original

  3. vs.[ Go to top ]

    Anyone care to comment on this vs JSR 208 and frameworks like ServiceMix?
    Reply to this Reply to original

  4. Re: vs.[ Go to top ]

    Anyone care to comment on this vs JSR 208 and frameworks like ServiceMix?
    ServiceMix has almost no relationship with SCA/SDO except in the most general sense. ServiceMix is an ESB (think EAI based on SOA/Web Services standards) with JBI support. There's no industry standard for ESBs, so every one of them is different and JBI support is ServiceMix's differentiator (along with EDA, which Gartner is suddenly saying is important). JBI and SCA/SDO have been compared several times. But JBI is really a subset of SCA/SDO, which is much more like a reference architecture for SOA. And SCA is also compared with Indigo (WCF) - which it is much closer to than JBI. In fact, several industry analysts have suggested that SCA is the IBM/BEA/Oracle response to WCF. I've written a blog a couple of months ago on what Forrester has to say on the JBI versus SCA/SDO issue: http://www.codefutures.com/weblog/corporate/archives/2006/04/forrester_on_sdo_sca_versus_jbi.html The summary is: -IBM and BEA did not support JBI in the JCP. Any Java specification not supported by the two Java industry leaders does not have a chance regardless of technical merits (think JDO) -SDO is fairly unique in the industry as the only data persistence API for SOA data services. So SDO could in fact drive industry adoption of SCA (Gartner predicts faster SDO market uptake) -Forrester (rightly) predicts that if the vendors that support SCA/SDO bring out products then it will become the de facto industry standard, regardless of which standards body manages the specifications PJ Murray, CodeFutures Software Data Access Objects and Service Data Objects
    Reply to this Reply to original

  5. Re: vs.[ Go to top ]

    P J, you seem to be engaged in an odd kind of FUD here. First off you say:
    ServiceMix has almost no relationship with SCA/SDO except in the most general sense.
    Which isn't entirely true because ServiceMix 3.0 does support SCA but I'll assume you didn't know that. You then go on to say:
    But JBI is really a subset of SCA/SDO, which is much more like a reference architecture for SOA.
    Which is also not true. In fact, of the two untrue statements, the first is probably more accurate since even your referenced articles and blog entries go on to say that JBI and SCA are complementary technologies. Clearly you have a vested interest in SDO's but why the JBI FUD? You also said:
    There's no industry standard for ESBs
    I can only assume that you mean that JSR 208 is not considered an industry standard for ESBs? Certainly looks like an industry standard to me. I agree that it's a shame that IBM and BEA decided not to support JBI but the only reason that this would be an issue is if SCA and JBI were competing technologies. Your SAP blog reference points out that SCA is probably closer to being competition to the JEE stack. Outside of the FUD, there are interesting questions related to both JBI and SCA: * Can JBI become the defacto ESB standard without support from BEA and IBM? * Does JBI need to become the defacto ESB standard? * Can SCA/SDO become the defacto SOA stack without a JSR? * Can SCA do asynchronous in-out MEP's or do you have to use their callback mechanism? * Does an homogenous middleware layer work? * Does an hetrogenous middleware layer work? * Why do so few people know about SCA/SDO given that Forrester seems to be giving it the thumbs up? * Why is a Code Futures guy so worried about JBI?
    Reply to this Reply to original

  6. Re: vs.[ Go to top ]

    P J, you seem to be engaged in an odd kind of FUD here.
    Well, I find your interpretation of posting odd. So we're even, I guess.
    First off you say:

    ServiceMix has almost no relationship with SCA/SDO except in the most general sense.Which isn't entirely true because ServiceMix 3.0 does support SCA but I'll assume you didn't know that.

    I got my information from the ServiceMix Web site: In short, SCA and Tuscany address an important, but different problem from JBI and ServiceMix. The two models not only serve different purposes, but we believe that they are actually compatible, and that an SOA may require both in the near future. Source: http://servicemix.org/site/how-does-servicemix-compare-to-tuscany-or-sca.html It's true that I didn't have up-to-date information about them adding SCA support. That's great news. It makes it more likely that others will follow.

    You then go on to say:

    But JBI is really a subset of SCA/SDO, which is much more like a reference architecture for SOA.


    Which is also not true.
    Why do you think this is not true? I'm hardly the first person to say this. Check this out: http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1179519,00.html?bucket=NEWS This article suggests that one possible future for JBI is to be a Java-only subset of SCA. If JBI is a subset of SCA, it will be a VERY good one. And it will position Java very nicely as the leading (preferred) language in a multi-language environment.
    In fact, of the two untrue statements, the first is probably more accurate since even your referenced articles and blog entries go on to say that JBI and SCA are complementary technologies.
    Well at least we agree that they are complementary technologies.

    Clearly you have a vested interest in SDO's but why the JBI FUD?
    I've no idea why you think I've any negative opinions about JBI.
    * Why is a Code Futures guy so worried about JBI?
    Where have you seen a negative comment by me about even a single aspect of the JBI specification or any product that implements JBI? My comments about BEA and IBM not supporting JBI were only in the context of a comparison of JBI and SCA. Apart from the personal attacks, that's an excellent list of questions, by the way. It raises several key issues. I'll leave it up to someone else to respond since I don't want to run the risk you reading more into my comments than I intended!
    Reply to this Reply to original

  7. looks complex[ Go to top ]

    It seems yet another apache incubator project related to services (there quite many apache projects related to services most in a not so active state). I've been browsing to the site for a few minutes and I detect a few vaporware smells: - lots of text but ever short on technical details. - non final, non standard specifications. I've never heard of SCA, DAS and SDO and I've been with my nose in many web service related specs over the past few months. Why do these specifications exist and why aren't they going through the regular channels. - total lack of a simple end to end example. I suspect that the helloworld example might amount to a fifty page tutorial, which might explain why it is lacking. In my experience, hello world is rarely simple in these kind of SOA vertical stacks of technology. - lots of spectacular claims with respect to compatibility with everything and the kitchen sink. Sorry, but it sounds like wishful thinking to claim that it will do all that in a simple way. It's a great way to sell technology because everybody is looking for simple solutions right now. I might be wrong but this doesn't look like something to get very excited about at this stage. It's one of the many attempts to make enterprise service buses easy. Most of these attempts are not quite production ready anyway. Either way the project page does not do a very good job of explaining the existance of the project and providing some comparisons with the many competing projects. For example, it seems to compete head on with JBI, which is actually a JSR and has a quite mature implementation. What problem does this project solve that JBI doesn't and/or why/how is this different from JBI?
    Reply to this Reply to original

  8. Re: looks complex[ Go to top ]

    - non final, non standard specifications. I've never heard of SCA, DAS and SDO and I've been with my nose in many web service related specs over the past few months. Why do these specifications exist and why aren't they going through the regular channels.
    You could perhaps start by looking up the SDO and SCA specifications in Google? For example: SDO 1.0 was JSR 235 (i.e. was approved by the JCP). If you were at JavaOne, you would have heard Oracle, IBM, BEA, Rogue Wave, etc announce products or product features based on SDO. For example, the latest release of WebSphere has enhanced SDO support. SDO 2.0 is multi-language and therefore probably not appropriate for the JCP.
    It's one of the many attempts to make enterprise service buses easy.
    The SCA/SDO specifications arenot related to the ESB design pattern in any significant way.
    What problem does this project solve that JBI doesn't and/or why/how is this different from JBI?
    This project is a reference implementation of the Service Data Object and Service Component Architecture specifications, which have the backing of BEA, IBM, Oracle, Sybase, Rogue Wave, SAP, Sieble, IONA, etc For JBI versus SCA, you could try reading: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2824 http://www.codefutures.com/weblog/corporate/archives/2006/04/forrester_on_sdo_sca_versus_jbi.html http://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html
    Reply to this Reply to original

  9. thinking beyond Java[ Go to top ]

    Learn to think beyond Java. Not everyone in the world is sold on Java, which is where services make sense. Btw, most of the web services related specs for services and their management is through "regular channels", well that is if you care to add W3C and OASIS in addition to JCP.
    Reply to this Reply to original