David Chappell Blog

In case you're wondering, this is the Dave Chappell formerly of Sonic Software.  I'm getting a lot of curious inquiries about why I chose to go to Oracle.  I departed Sonic/Progress in December, and I have been doing some consulting while I made the interview rounds with all the usual suspects of SOA infrastructure vendors large and small.  Oracle seemed to be the right fit because they're well fitted with the right technology, and I like the entrepreneurial spirit of Thomas Kurian's team.  Its kind of like the Sonic/Progress relationship but on a much larger scale.

I'm going to remain Boston based but I'll be traveling to Redwood Shores quite a bit.  I'm already getting deeply involved with the product teams on architectural direction, which is a tremendously gratifying experience.  In addition I will be traveling around the world doing conferences, seminars, customer visits, etc just as before.  I'll probably start the next book sometime this year.

I did my first public speaking gig as an Oracle guy yesterday at JavaOne.  I was on an SCA panel with Mike Edwards from IBM, Mike Rowley frorm BEA, Sanjay Patel from SAP, Mark Hapner from Sun, and Tibco.  It was moderated by the other David Chappell (the Microsoftie).  How cool is that!?  A few of us went out to dinner afterwards and then came back for an 8:00PM SCA BoF.

So anyway, back to the "Why Oracle" question.  Earlier this year I spent some time as a consultant at a Boston based financial services firm, helping them with their SOA strategy.  I came in at the tail end of their evaluation of SOA infrastructure vendors and discovered that they had chosen to go with Oracle.  Their decision was based on a fairly thorough RFI and PoC process to prove out the technology, and then backed up by the knowledge that Oracle had the strength and size to be a long term partner should any issues come up during their multi-year SOA initiative.

Oracle had always been in my top 3 candidates of places I wanted  to land, and witnessing this unbiased view from an end-user just made the decision to join them all the more easier.  Here are some additional points -

1 - Market Momentum.  As seen during my time as a consultant, watching customers do independent evaluations and select Oracle.  It's clear Oracle is a leader in this space.

2 - Unified Architecture.  The SOA infrastructure vision at Oracle is a strong one.  Oracle has assembled a number of components that provide a comprehensive SOA infrastructure, which they have combined into a well-designed, unified architecture.  Oracle went through the bulk of its acquisition of the necessary pieces and the subsequent integration pains over two years ago.  Other companies in this space are just now trying to figure that out, and the result is apparent to the customers who are evaluating the products. 

3 - Scalability.  Oracle has a focus and a set of unique capabilities to address the scalability requirements for true enterprise SOA deployments.  And that capability has just been strengthened by the Tangosol acquisition.  Scalability has always been an Oracle strength, and I have had plenty of experiences where I witnessed first hand how important that is for enterprise-scale SOA.

Dave

I recently participated in a panel discussion on SCA at JavaOne.  The panel included Mike Edwards from IBM, Mike Rowley frorm BEA, Sanjay Patel from SAP, Mark Hapner from Sun, and Tibco.  It was moderated by my namesake, the mostly-Microsoft-centric consultant David Chappell of Chappell & Associates.  David asked questions which we took turns answering during the first half hour, then turned it over to the audience for questions for the 2nd half hour.  The panel went pretty smoothly, with 2 of audience members taking time at the "question" mic to tell the rest of the audience that they were already big fans of SCA. 

The only somewhat contentious point, which Mr Chappell was trying to tease out of the panelists, was whether SCA represented a new programming model, and if so does that mean we are adding complexity over JEE and JAX-WS, or whether we are simplifying it.   My answer to David's question about whether Oracle liked the Java programming model is that we had some folks who had some issues with it, but we may still consider it in the future.  I stated that we do allow you to call java classes from within an SCA composite, and package them up in the same jar file, we just haven't yet bought into the whole Java programming model yet (more on this in a bit).  I think it was because of this that the other David posted a blog which portrays some misalignment between the vendors.

I went to dinner after the panel with my distinguished namesake and Mike Rowley, joined by Gregor Hohpe of EIP fame, and Jim Marino and Jeremy Boynes from the Apache Tuscany/Fabric 3 projects.  We had lots of great discussion around the question of where is the "service" in SCA?  David seemed a bit perplexed over whether an SCA composite can be split up and deployed across different platforms.  Gregor had missed this point in earlier analysis of SCA, but then joined in the why can't you split it up camp, which prompted him to write this up  -

When I looked at SCA before it totally escaped me that the spec assumes that a composite has to run in a single vendor environment. This limitation means to me that SCA has relatively little to do with SOA, which has to deal with an environment that is heterogeneous and not controlled by a single vendor. This does not mean that SCA is useless, but it means that it targets "programming in the middle" (wiring components in a single vendor environment) as opposed to "programming in the large" (wiring services in an enterprise setting). This makes all sense because the "programming in the large" is the realm of the WS-* specs but it was still surprising to me that I missed this critical part.

So here is Oracle's take on the multiplatform issue - - the SCA specs say nothing about single node/multi node, single platform/multi-platform. There is no restriction if the particular implementation chooses to make that work.

That being said, the model as it stands kind of presumes that a composite can be used to model a unit of deployment.  The first order priority is to make sure this is portable, however the assembly spec should be sufficiently flexible for folks to use this in different ways.  In principal, since composites can recursively nest other composites, you can implement a system that fans out the leaf nodes to different systems but treats them all as a part of the same "administrative" domain.  We came to concensus about that over dinner and I thought we all agreed it was a good thing.

On the Java programming model issue, I think the mostly-MS David Chappell is missing the value proposition of SCA. The current Java programming model is not the most central part of SCA.  SCA allows one to create composite applications using a variety of different technologies, languages, frameworks, transports, protocols, then wire them together, configure them, deploy, manage them. You can do that for SCA-enabled technologies, for non-SCA-enabled technologies (using existing artifacts),  as well as have external (non-SCA) dependencies.   In his blog David correctly characterized that Oracle's view on the value prop of SCA is mostly about composition.  In the panel discussion I pointed out that SCA is a stated direction for our own internal architecture for Oracle Fusion Apps and Fusion Middleware.  That means we'll be using it to let you build apps that combine your business logic with BPEL processes, business rules, BAM components, CEP etc all rolled into discrete SCA composites that can be individually deployed and managed.  In keeping with the spirit of our hot-pluggable architecture, you'll be able to deploy that on a variety of appservers and containers, whether EJB3 based or Spring based. 

First, lets call out and be clear about what the "Java programming model" is in JCA.  Here's some background info on the Java Component Implementation spec (JCI) and Java Common Annotations and API spec (JCAA).

I spoke with Anish Karmarkar, one of the Oracle engineers who is working on the SCA collaboration, who had this to say - JCI, which is the particular Java language binding is a small spec that talks about how to do implementation.java. The common API/annotations spec is meant to be used by all kinds of Java-related specs including Spring component implementation and JavaEE integration. What we don't want to see is something competing with established/preferred models for web applications. Trying to destroy Spring is a mistake, for example. We want SCA to be the model for building network facing services first and foremost.

In addition, most of what I think the other David means by programming model is about SCA metadata that gets reflected into technology-independent SCA artifacts (composite, componentType, constrainingType). The only specific programming construct that is very likely JCI-specific (although it is defined in the common API/Annotation spec) is the ComponentContext class. This class is useful only in unmanaged environment or when dependency injection is not possible. Even when using JCI, I don't envision that people would use ComponentContext, but instead use the @reference, @property, @service (and related) annotations.

Sanjay Patil, Greg Pavlik, and Mike Rowley have posted detailed responses about one of the other issues of contention, which have to do with the programming model -

Sanjay -

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/6567

Mike Rowley -

http://dev2dev.bea.com/blog/mrowley/archive/2007/05/does_sca_define.html

Greg Pavlik - http://gregpavlik.blogspot.com/2007/05/other-dave-on-sca.html

Cheers,

Dave