DeCare Systems Ireland Blog

Even though 'Service' comes first in SCA (Service Component Architecture), SCA is a distributed component model. It's about designing components (and composites) rather than designing services. It doesn't feel like it was designed to build a SOA. It feels like its main goal was to define a distributed component model. And as we all
know, the distributed component models failed in the past. I think SCA will too.



For the second day of JavaOne my schedule contained technical sessions and BoFs about mostly SOA, SCA, REST and Comet.

SCA

I attended two more sessions about SCA:
- Open-Source SOA with SCA and Apache Tuscany
- Open Standards for SOA and Java technology

The second one was a panel session. The host was MC David Chappell of Chappell and Associates and the panellists were David Chappell of Oracle, Mike Edwards of IBM, Steve Jones of Capgemini UK, Patrick Leonard of Rogue Wave, Mark Little of RedHat, Sanjay Patil of SAP AG, Michael Rowley of BEA Systems, Inc., Scott Vorthmann of TIBCO Software Inc., and Peter Walker of Sun Microsystems, Inc.

My first comment is about the name of the panel: It was all about SCA, so why was it not in the title of the session? I think people find a catchy name first and then they come up with the content…

I remember, the first time I read about SCA in late 2005 (a series of articles from IBM, I think), I had the same feeling that I had today: I think SCA is an attempt from Java EE (then-J2EE) vendors to find another way to sell their containers (sorry… “runtimes”) and development tools after the decline of bloated application servers.

Even though “Service” comes first in “SCA (Service Component Architecture)“, SCA is a distributed component model. It’s about designing components (and composites) rather than designing services. It doesn’t feel like it was designed to build a SOA. It feels like its main goal was to define a distributed component model. And as we all know, the distributed component models failed in the past. I think SCA will too.

SCA promises component reusability. However, one of the dangers that I saw today was reliance to a single vendor’s runtime. I haven’t tested it personally but the panelists’ answers made it clear that there’s no guaranteed portability between vendors’ runtimes. It is clearly said that “SCA is about interoperability and not about portability”. Not to mention .NET, which doesn’t support SCA. So, it’s mainly a Java thing. I know one can write components in JavaScript and even in BPEL but in JavaOne, it’s about Java, right :). Not sure who would like to write a component in JavaScript.

How real is SCA? I have only seen or heard of a few case studies. And I found it odd that, among the panelists, Steve Jones was the only one developing a production application using SCA. His comments showed why one can get easily confused about what SCA really is. He said that SCA helps in organizing the development teams and operations. And it was also said that it’s an architectural and operational technology. But I’m sure SCA didn’t start with this intent. Maybe, it’s trying to fit a niche now but a technology won’t succeed by getting away from the developers. Furthermore, the concept of an SCA module that can export and import other modules is very similar to OSGi’s. So, if you’re looking for modularity in Java, I’d recommend OSGi just as if you’re looking for Web Services, I’d recommend Resource-Oriented RESTful Web Services.

These sessions attracted a lot of people, the halls were completely full. And it is encouraging that the people I talked to at the end of the sessions were as skeptical as I was. I think, as an industry, we’re adopting an increasingly pragmatic approach to new technologies and techniques. How can’t it be that way? 24 hours ago, we attended a talk about the case study of a grid-enabled SOA capable of handling 35 million transactions without SCA, JBI, BPEL, WSDL etc. Another question that came to my mind was: Why haven’t we had case studies about SCA or JBI? I have a few more sessions to attend until the end of JavaOne… We’ll see…

RESTful SOA

The technical session entitled “It’s All About the SOA: RESTful Service-Oriented Architecture at Overstock.com” was my only one about REST (Representational State Transfer) today. And it was a case study presented by Ian Robertson and Sean Landis.

Overstock.com started, probably like most of the now-big companies who built their business on the Web, with a monolithic, quickly put together code. It was written in C. This reminded me of my first Web development days in 95-96 when we used to do CGI development in C. I can’t say “Good Old Days!” because the days are much better now. At least at work :).

Overstock.com is a Utah-based online retailer. It was founded in the late 90s under the name Discounts Direct and underwent a name change in 1999. They used the Web to sell surplus and returned merchandise.

When it was time to improve their system, they switched to Java and then to a SOA. Their main motivations to put in place a modular service oriented architecture were:

- To use web services
- To better isolate some sensitive data
- Facilitate concurrent development across various teams

They also had a Web site for mobile clients that could take advantage of common services.

As part of their analysis, they looked at various underlying technologies to build their SOA on:

- Java RMI: It was a simple option but it had poor support for load balancing and failover.
- JERI (Jini Extensible Remote Invocation): It was too complicated
- Web Services: They were ideal for a Web development house. However, like many others, Overstock.com found SOAP and WS-* too heavy, therefore REST looked very promising.

REST stands for Representational State Transfer and it started as the PhD dissertation of Roy Fielding, who is also one of the principal authors of the HTTP specification. It is a style not a standard. It is a set of design criteria but not an architecture. And its main concept is to fully use HTTP rather than using only one of its actions as a mere envelop to pass XML data. This idea includes using HTTP methods such as GET, POST, PUT, DELETE and HEAD as they were intended to be used, at first, when a bunch of scientists were using by-then-non-public Web to collaborate. Even though it’s back to basics, this constitutes a major mindset-shift in programming for the Web because most of the Programmable Web isn’t used the same way as we browse the Web using a browser.

The presenters continued their talk by explaining the architectural style of REST (Client-server, layered, stateless, cacheable) and the importance of the concept of Resource. A resource is some data that can be held on a support and represented as a data stream when it’s requested. This can be an image, a document, the result of a computation etc. A resource has to have a URI, therefore the target of a URI is a resource. One of the beauties of a resource accessible by a URI is that the URI can map to different representations of the same data. For example, if the current temperature of Cork (Ireland) is requested, the response can be a text saying “Rainy, 15″ or an image of a rain cloud with “15″ printed on it.

REST has some principles and best practices:

- A URI for each resource
- Logical URIs over physical ones. For example it’s better to have:
http://www.decaresystems.ie/services/java/perftuning
rather than:
http://www.decaresystems.ie/services/java/perftuning.html
- Nouns, not verbs are used as part of the URI (http://www.example.com/java/jdk/version)
- GET has no side-effect on the system, it doesn’t cause any modification etc. The client “gets” some data, that’s all. Therefore GET is a safe action.
- To link responses to other requests by using links in the responses.
- To minimize the use of query string
- “/” represents concepts like “parent/child” or “whole/part”
- Gradual unfolding: A resource representation should contain links to get more details.
- GET is the method to use when the client needs a resource representation, not the POST method.

In the RESTful world, the SOAP-based Web Services are called Big Web Services. The matrix below compares them:

Going back to Overstock.com: They are an agile development house. They wanted to use Java SE to develop Web Applications without magic. They favored simplicity and performance (cut off the fluff: SOAP). The deployment of their application became extremely simple as well just by using a simple Servlet container. They adopted Restlet as their REST framework. Furthermore, as part of their internal development framework, they extended it and they contributed back their additions.

I’m going to open a bracket about Restlet here, because it really deserves it. Restlet is a REST framework in Java created by Jérôme Louvel and first released publicly at the end of 2005. He developed the first version of his framework that was going to become Restlet, on top of the Servlet API. Then, he decided to bypass the Servlet API and developed the first Restlet connector that issued direct REST uniform calls. Later he split the Restlet project in two:
- Restlet API: Generic classes
- Noelios Restlet Engine: Reference implementation, server and client connectors, etc.
Today, Restlet provides a solid ground to build RESTful Java applications.

So, in Overstock.com, they adopted REST but they had to spend some effort to create the mental shift to Resource-oriented architecture. And they found that testing and team coordination (including release and deployment coordination) became very important.

Some lessons learned:

- SOA has a cost of adoption. The project team needs to be educated.
- Resource-orientation and REST require a different mindset (compared to the traditional Web App development). Richardson and Ruby’s RESTful Web Services book was the required reading (It is an excellent book. If you’re in Web development, I definitely recommend it).
- Looking back, they think they should have done a better job on the business analysis.
- Version management has always been a challenge.