In case you thought the SCA rock stopped rolling...

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.

Tuscany Graduated

A quick shout out to my colleagues and all the folks who have worked so hard to develop an open community which supports Service Component Architecture. The Tuscany project at Apache has recently been promoted from an incubator project to a fully endorsed ASF top level project. This promotion recognizes the community for fostering an open and diverse membership, demonstrating capability to deliver stable, working implementations of the technology and also garnering the votes and confidence of the Apache Board. Congratulations on your success! Super job.

Multi-Cores, SOA, SCA and the Incredible Lightness of Being

I received a link from a colleague regarding a recent article "SCA applies SOA principles to Apps Design" by Andy Dornan. The article starts off with a slant that SCA enables runtimes to take advantage of multi-core CPUs; further implying that while Moore's law still is applicable for making the processors themselves faster, that the real leverage in software gains comes from building applications that can have multi-core processors thrown at them. He theorizes that in order to really leverage the multi-core processor future, that applications must be broken up into small loosely-coupled components. And this was just the first paragraph.

Whoa. Where to start. I can say the article made me think, does SOA, or SCA for that matter really help applications deal with multi-core processors? Far be it for me to criticize semantic English, but multi-core processors imply same-box, and the focus of SOA and SCA relate to the wider, distributed network; which may be comprised of multi-core processor nodes. Certainly SOA does help application developers in arriving at application patterns and best practices that lend themselves to being advantaged by multi-core processors, or even more importantly a set of distributed processes and processors. Simply using container-based applications like JEE or even Spring put the majority of the burden of thread management in the hands of the middleware, where presumably there are appropriate controls and exploitation of multi-core processors have been meticulously built; that really doesn't have much to do with SOA or SCA. Billy Newport has blogged numerous times about applications and multi-core issues as well. While there has been lots of research in predictive instruction execution and pipelining, SCA offers more like a circuit board assembly than a flow chart (perhaps like BPEL) and its model doesn't really imply any ordering or sequencing which would afford any great advance in multi-tasking. Certainly SCA has asynchronous invocation concepts which would allow for a greater opportunity for muli-tasking, but I would hardly say they are transparent to the application.

To cut Andy a break, perhaps what he intends to say is the SOA and SCA programming style of providing declarative dependencies and policies allow the runtimes to better understand the application and therefore, de facto have a better chance of exploiting the hardware available to solve the problem.

The article then diverges into other topic areas for which I also have some comments.

• Java is certainly an important language for SCA to embrace and to treat in a first class manner, but it is hardly the only language. Certainly at least BEA and IBM and keenly interested in SCA assemblies with BPEL implementations, but there is lots of activity in other languages. Of course WebSphere is going to focus on Java -- it is a Java runtime. What will be interesting is how vendors choose to slice and dice the type of component implementations they support and in what form factor they will deliver that support.
  
• I didn't quite understand his comments about requiring a higher-level intermediary to embrace WCF components. Certainly WCF components can consume or be exposed as Web Services, using WSDL and XML for interface definitions -- SCA embraces both service consumers and providers. Perhaps I'm missing some other point Andy is trying to make. Certainly, as I've blogged about before, SCA embraces existing (legacy) technology and I don't understand why anything would have to be rewritten. This seems just wrong to me.
  
• I don't agree with the statement that the vendors believe SCA is needed to achieve "tru(e) platform independence." What SCA allows you to do is to compose and assemble applications written in a variety of implementation languages, hosted on a variety of platforms and insulates the business logic developer from having to have unnecessary knowledge of these implementations.
• Microsoft is not interested in application portability, so certainly aspects of SCA are not interesting to them; however, the author does seem to be unaware that SCA, albeit in its original proprietary, has been shipping in WebSphere Process Server 6.0 for some time now.
• Service Data Object is not an optional subset of SCA. SDO is orthogonal to SCA, but is rather complementary... to be honest, I just don't know what Andy was trying to articulate in his closing paragraph about SDO.

At the end of the day, I suppose its nice to see some articles coming out regarding SCA.... even if the ideas in the articles, I can't get my head around.

It's a Dessert Topping AND a Floor Wax

There has been some recent blogging about general confusion on whether or not SCA constitutes a new programming model or not; for instance Dave Chappell blogs here, Mike Rowley of BEA here, and Sanjay Patil of SAP here.

Of course SCA defines a new programming model, however, it also specifically defines an invocation model, a component model, and an SOA assembly model which embraces other, non-SCA programming models. Blur in the fact that the term "programming model" has specific language connotations (at least in my mind), while SCA and its cousin SDO were designed to be specifically language neutral.

What we need for building SOA applications is a contract to describe dependencies, policies and implementation with as little knowledge of or need to impact existing business logic. It needs to lift us out of the computer science goo and into building business logic that is meaningful to the business.

The fact that one can or cannot use SCA with or without another container, or as a client with any at all is less important in my mind as the importance of its design points of separation of concerns and insulating the business logic from specific protocol and data bindings which lead to fragile, inflexible applications.

Steve Kinder

Just for Terry

Since you are both a user experience guy... and a self-denying Microsoft watch dog... I thought you might find this video "What if Microsoft designed the Ipod?" entertaining. I did.

Certainly, we Webspherian's can learn a few lessons. Einstein is attributed to say, " Everything should be made as simple as possible, but not simpler. "


Steve Kinder

It really is Christmas Early... or is that Holiday Season?

Hot off the presses, a refresh of the latest externally available beta drop of the SOA Feature Pack for WebSphere V6.1 is available here. This feature pack leverages the Apache Tuscany open source technology from the Apache Incubator project to provide an implementation of the published Service Component Architecture (SCA) and Service Data Object (SDO) specifications implemented at by the OSOA Collaboration of vendors.
If you haven't heard of SCA and SDO, where have you been? :-) We are very interested in getting feedback on what we are doing right, but especially what we are doing wrong with these new SOA related programming and assembly model concepts.

Happy Coding...

Steve Kinder

p.s. I forgot to mention that the SOA Feature Pack installation also installs the Web Service Feature Pack, as we base our Web Service support on the new AXIS-2 runtime. If you happen to download the SOA Feature Pack, you get both feature packs.

SO-UH... IT SOA Part 4. No, really separation of concerns.

From the previous blog site, I've had 3 entries on exploring why the SOA vision isn't really hard -- not to be confused with the reality in the industry -- which is nonetheless quite difficult to sort through. At any rate, so far I've stated that Service Orientation is important because it gives the industry a common approach to develop, design and speak of distributed applications; that in order to be successful, SOA principles must at its heart embrace our existing technology; and that finally, a greater level of flexibility can be achieved by ensuring that our service consumers and our service providers have a level of independence -- an appropriate level of separation of concerns, such that provider implementations can be changed with independence from and of the consumers.

To really achieve a separation of concerns between the service consumer and service provider, it is often beneficial to introduce the concept of service virtualization. Service virtualization is the concept that we don't actually publish the concrete service provider to consumers, we publish an intermediary which exposes the formal service interface and business contract. In its simplest form, the intermediary is really just a pass-thru which merely passes parameters and context to the real, concrete service provider implementation. In more complicated forms, dynamic decisions can be added to the intermediary to choose the most appropriate service provider implementation. A very simple business example is the famous "getStockQuote" service. Some stock quotes are delayed 20 minutes but are free to obtain; whereas real time quotes usually cost the consumer a small fee to obtain. Both provide the same service, one has a greater expense to the business, but better quality of service. This intermediary is sometimes called a mediation.

Service virtualization is one of several beneficial aspects of Enterprise Service Bus patterns.

Bottomline: Separation of concerns is a good thing to build flexible, agile applications. Best practices and newer programming constructs can achieve a good deal of separation of concerns. Service virtualization complements these concepts, and extends separation of concerns to older programming styles, patterns, languages. Service virtualization facilitates us embracing legacy applications, utilizing them where they are hosted.

Steve Kinder