I'm very pleased to announce to this community that we have made active the first beta of the newly re-based Feature Pack for Service Component Architecture for WAS V7.0! My team has been killing themselves, slaving away using new agile processes, keeping on top of the latest WAS builds to bring you this technology on the new WAS! To sweeten the pot for some of you out there, and you know who you are, we are even offering the feature pack beta in a popular VMWARE distribution which is configured to run a SUSE Linux guest with the SCA Feature Pack and WAS V7.0 betas pre-canned and ready for you to play with. Our development and beta teams are excited to engage all of you SOA application developers out there-- welcome!
Beta details here. Of course, our code is based on the Tuscany open source project which I've blogged about before.
I want to thank all of my development and beta team members for all of their hard work.
Farewell to IBM
10 years ago
6 comments:
Hi Steve, great to read about the new feature pack release. Can one use WID 6.1.x to code the SCA modules to run on this new pack on WAS 7 beta? Would the generated code differ in some way based on the target runtime (WPS vs WAS+FP)?
Plus wasn't there a similar feature pack for WAS 6.1 earlier? How does the two compare?
As you may or may not know; the IBM version of SCA, sometimes called "Classic SCA" or "SCA 0.5", that is featured in WPS was used to seed the Open SCA architecture and the OSOA collaboration shaped and refined certain aspects of the architecture to adopt other vendor's points of view and design needs. While that means Classic SCA and Open SCA are similar and have the same concepts, they ultimately are spelled somewhat differently. The WID 6.1.x toolset is designed for Classic SCA only. That said, we are introducing SCA tools into RAD, although the availability of a beta or GA of those tools are not public at this time.
The V7 feature pack is extremely similar to the 6.1 version, in fact its a continuation of the project -- it has the same code heritage (based from the Apache project Tuscany which has formally graduated from incubator) however the code was reworked to run on a WAS 7.0 base. This is trickier than it sounds but needless to say, we've upgraded the Tuscany base, reworked to run on WAS V7. The V7 feature set has pluses and minuses over the 6.1 version. One neat new thing (as mentioned in the initial blog entry) the V7 beta offers is a VMWARE Image of the V7 WAS Base Beta with Feature Pack installed so one can evaluate the SCA technology and not have to be focused on how easy (or difficult :-) we are to install. 2 notable missing technologies however are: SDO. We've learned a great deal in our experience with the WPS stack regarding SCA and Data Objects, and the current SDO 2.1 specification has a number of issues especially around its treatment of XML. Our architecture teams are engaged at OASIS to deliver a more XML-centric SDO in the 3.0 version which we believe is fundamental to an SOA. We will look to restore SDO technologies when we can reconcile these technology issues.
The other withdrawn technology perhaps of interest is support for JMS bindings. The implementation of the JMS bindings that appeared in the 6.1 beta was scaffold and required us to generate and deploy an MDB into WAS without natively supporting the SCA components. Project priorities have left us with some hard choices and our team decided not to delay the rest of the feature pack capabilities to contain the proper design and implementation of JMS. That said, JMS Bindings are a key, top priority of our follow-on requirements.
Thanks for your interest in the project and we are eager to get your feedback!
Can SCA work without the use of SDOs?
Absolutely SCA can work without SDOs; the V7 beta supports JAX-B and PoJo objects as bindings to Java SCA components. The architecture of SCA is such that it is essentially databinding agnostic; in the that there is a separation of concerns between the programming model that is presented the business programmer and representations of that data by the service partner (consumer or provider), and further the wire format of the data. As I said before in this thread though, we view SDO as an important databinding option and are looking at it as we flesh out our support for SCA.
Thanks for the SDO answer Steve. My concerns around SDO are primarily about the overhead incurred by any transformations happening.
My environment is all Java at the moment and it seems like a high price to pay. I do like the concept of decoupling the consumer from the service however isn't the reality that there is some coupling inherent just by referring to a field by the same name?
Even though your application is all Java, there is a certain fragility that is caused in service parameter data being described by a simple PoJo class. Both the consumer and provider have to agree to be java, and they both have to have a class that can deal with the java serialization. (SCA supports this style, and the beta does as well; but in my mind this style is most appropriate for Local Services; where you know the environment is contained to java.) When you expose a service for a remote requester, it is common to have .NET clients; when you use a service that is not in your domain, like at a service provider like salesforce.com or target a mainframe server hosting CICS; you are likely flowing out of the java world even though your application is all java. In these cases, it is better to use a formally described service interface with schema-defined data for parameters as the agreed-to business interface; and have the application environment present a natural view of that interface for the business programmer. This separation allows us to free the consumer and provider from having to know too much about each other. Sure they agree on the business contract; that is good -- but the agreement does not force either party to a specific programming language. JAX-B provides the linkage to the schema-defined data for the Java Programmer; and provide a better, language-neutral data interface. (SDO does this as well.)
Post a Comment