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.
- SCA forces a dependence on development tools.
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.
- SCA discourages the creation of well designed service contracts.
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.
- SCA is big (as implied by the comment about the gigabytes of Oracle code).
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.
- SCA has too many moving parts
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.
- BPEL 2.0 is in its infancy
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?