searchSOA.com has just published a story on SCA (Service Component Architecture) which describes some of the benefits that SCA delivers for developers of services-based process applications. You can read the full article here, including the comments of our CTO, Dr. Michael Rowley.
We are pleased to announce that Dr. Michael Rowley, Active Endpoints CTO, will be presenting a talk on the Service Component Architecture (SCA) at the UCLA Java Users Group on Thursday, August 27, 2009. Details are in the media advisory attached to this post.
I’m pleased that my recent disagreement with JP Morgenthal was noticed by Joe McKendrick, on his Service Oriented blog, and by Loraine Lawson at ITBusinessEdge. Now, having set the record straight, we can step back a little and start a more general discussion about SCA and why it’s a powerful new approach for developing applications. Loraine made a few comments in particular that got me thinking more about the value of SCA to a chief architect who is “prioritizing and rationalizing applications from an enterprise perspective.”
Once this architect has prioritized the needs of IT for the enterprise, it is critical that the architect’s development team has the right “tools” to update or create the applications that will meet those enterprise priorities. The development team also wants to improve its ability to maintain the application in the long run. I put the word “tools” in quotes in the previous sentence to emphasize the fact that I am using the word in its most general form. Your programming language is a tool. The design patterns you follow are tools. And, of course, the middleware infrastructure you use is a tool. J.P. is just wrong to assert that SCA will lock you into dependency on a vendor. There is no reason that middleware has to lock you in to a vendor any more than using a programming language locks you into a vendor, but that is only true if the middleware uses…
standards (and the right standards at that). If SCA were just some vendor’s tool that was promising great things, J.P. and everyone else would be right to be skeptical. But it isn’t proprietary, it’s a standard.
There are a few important reasons why this is important. It is always difficult to hire people who are skilled in a vendor’s proprietary technology and any application that depends on the technology is always at risk, since the vendor may choose to “improve” the technology in a direction that is retrograde for you. Or, the vendor could possibly abandon it altogether.
A good middleware standard is like a high-level language. It raises the level of abstraction that developers work in, so they can think about the actual problem being solved instead of fiddling with bits – or SOAP headers. There are three recent standards that do exactly this: BPEL, BPMN and SCA. BPEL is a language that is specifically designed around creating and using services, so it is also inherently middleware. Then there is BPMN, which standardizes the notation — the look of the business process on the design canvas — so that developers and non-developers alike can share an understanding of what is going on. And finally there is SCA, which allows developers to create, wire, package and deploy services without having to sweat the details of the numerous WS-* standards for every service that is created or used. It, like high-level languages, raises the level of abstraction without significantly constraining what a developer can accomplish.
Forcing a development team to avoid recent advances in middleware today would be like having a manager in the 1970’s forcing their developers to program in assembler due to a mistrust of languages like FORTRAN. Productivity would suffer.
When JP Morgenthal saw the announcement of the Understanding SCA book (which I co-authored), it prompted him to post his thoughts on the problems with SCA. He developed his thoughts during a recent investigation into SCA, but his post leads me to believe that he misunderstood some of the key characteristics of the new standard. Here are some of his criticisms and the reason that I don’t believe they are accurate.
No. As we were working on the standard, we primarily talked about the development experience for a developer who is just using a text editor. We did this because we understood that you can’t make fundamentally complex technology simple by creating layers of development tools. The place where that approach usually falls apart is in debugging – especially debugging after deployment. If a technology is truly simple, as SCA strives to be, then it should be possible to create it in a text editor. Tooling still can be useful, but just as a productivity accelerator.
Not true. A WSDL-first approach can and should be used, but not as the only way to define reusable code. Developers with SCA are encouraged to distinguish the software that will used and reused locally within an application from the services that will be exposed remotely. This way developers can concentrate their attention on creating evolvable, loosely-coupled coarse-grained services. Early versions of J2EE made the mistake of saying that all EJBs must be remotable, which resulted in the creation of tightly-coupled, fine-grained components that could never really be reused enterprise-wide. We learned from that mistake.
Check out the Fabric3 SCA runtime. The download for the stand-alone server is 10 MB. Yes, Oracle includes SCA in a package with all the other middleware they’ve ever created, but that really isn’t the design center for SCA. It was designed to allow for small, simple runtimes. Some people have criticized us for not building on top of JavaEE standards, but that was done on purpose. We don’t want SCA to be just one more thing that has to be learned in addition to everything else that developers currently have to learn. It is intended to be the smallest amount of technology necessary to build a service-based application.
Actually, creating an application with SCA generally results in fewer artifacts than developing the application with Java technologies (JAX-WS or SpringWS). This is especially true when you use SCA and BPEL together, since BPEL code declares constructs using XML Schema and WSDL port types directly. If you use either JAX-WS or SpringWS, you end up creating Java classes for every XML element in every document used by a service. This can result in hundreds of classes, each a separate artifact that has to be managed.
JP included this criticism as the reason why it cannot be yet be trusted. BPEL is related to SCA, since SCA encourages the creation of services using BPEL.
Actually, BPEL 2.0 has been out since April of 2007 and people have been successfully creating service-oriented applications with it ever since. More recently, with the advent of BPEL4People and WS-HumanTasks, more and more developers are finding that the standard works very well for more traditional workflow scenarios. It is also the best standard to invest in, since XPDL is so loose that portability between tools using the standard is very weak.
Take a closer look
I believe that SCA is a key new technology that will help people achieve the very goals that JP is striving for: greater simplicity, better service design, higher productivity and less dependence on large software stacks. I hope that JP, and anyone else who is interested in these goals, takes the time to take a closer look at the technology. However, reading the specifications might not be the best way to get an understanding of the technology and how it can fit into an organization. May I recommend a book? 
Active Endpoints’ CTO Michael Rowley, Ph.D has just co-authored a new book on the Service Component Architecture (SCA) along with Jim Marino, Ph.D. of Metaform Systems. The press release attached to this post includes a link to a website that offers a coupon code for a special discount that can be applied to a purchase of Understanding SCA (Service Component Architecture).
