April 2007 Archives

Service component architecture

I've been puzzling for some time what the point of the Service Component Architecture and Service Data Objects, standards from the Open SOA alliance are "really" for.

SDO I sort of understand: it's a cross-language data binding API for services, competing with Microsoft's ADO.NET.

SCA on the other hand, has been quiet for a long time, though 1.0 was released on March 22. For a while, I thought it was a way to wrest control of the deployment model for component software systems away from Java, to enable a truly cross-language containment and configuration of distributed systems. It still is this, to some degree: component implementations so far can be in (simple) Java, Spring, BPEL, C++, though Java remains a kind of unifier.

But it's clearer what else it is, from my first read of the 1.0 specifications. This is my first impression, not necessarily canon:

- It's a specification for how services & dependencies, with different kinds of transport or transfer bindings, can be assembled, wired together, and deployed when within the control of a single agency.

- It specifies how implementation technologies (not just Java) can implement service capabilities.

- Thus, SCA a framework that treats services logically - not just as web services. WSDL can serve as the cross-process interface definition, but a Java interface can serve as a service interface for "in-process" SOA.

This enables multiple implementations, whether C++, Java, or eventually PHP, Ruby, etc. to have bindings and in-process exposure to any other SCA component registered within a Java virtual machine itself, or out-of-process exposure via WSDL/SOAP or a custom interface type & binding.

In practice, this means no more futzing with JNI or JAX-WS when integrating disparate components, the SCA plumbing will take care of this wiring and type marshalling. Though you'll either have to wrap your implementation with the SCA API or conform to a particular interface binding.

- It's an attempt to show that Spring dependency injection and OSGI bundles can serve as the plumbing needed to make the JVM itself a bus between in-process services, so long as the interfaces are published and evolved independently from the implementations.

- It's another run at the Beehive fence, in an attempt to create a productive development and deployment model for services that competes with Microsoft.

Five years ago, BEA came up with a crazy idea to make Java web service & web development as productive as .NET 1.0 -- the result was WebLogic Workshop (WLW) and its notion of "Controls". While WLW was a modest success, Beehive spent ~2 years in proprietary incubation at BEA as the "Weblogic Workshop framework" before being spun out to Apache, which tainted its adoption, as it was largely tied to an IDE and had a set of newish code annotations (which Java didn't have support for back then).

This time, SCA seems to be much further ahead: with a broader mindset that includes multiple implementation technologies, lifecycle and deployment going beyond EJB, a richer competitor to compare with (Indigo / Windows Communication Foundation), and long list of partners at the table besides BEA, including some of its biggest competitors.

This is definitely the kind of innovation that the SOA community needs. It is open minded enough to enable many representations of service interfaces, implementations, and bindings. SCA unfortunately doesn't focus on network-scale service interoperability with RESTful interfaces, but I don't think it will necessarily prevent the adoption of it once the industry gains more understanding of how a programmatic RESTful interface, implementation & binding should look (beyond a Servlet ;).

A quote, by a CIO, on Web Architecture vs. Client/Server Architecture. This passage (from an out-of-print book) highlights, for me, why there are philosophical divides in this architectural debate to this day. I will also note that this reflects common sense today in certain crowds -- the rise of the stupid network, the end to end argument, Emphases are mine.

"Webs are spun out of fine threads, but they get their strength from clever design and a capacity to overcome local failures. Much of the promotion of client-server methods implies that by distributing existing computer power you gain in economy and reliability. If you leave the existing hub network in place without alternative database management practices, and locate the new servers at the ends of the existing hubs, your support costs as well as risks will increase. Your costs will increase because you will have many more data centers to attend to. Your risks will also increase because your points of vulnerability will be greater.

When it comes to computing, I believe that all networked computers are created equal. Some may be richer, some may be poorer in terms of power, functions, or resources. However, I consider it a matter of good prudence that all computing resources should be able to connect to each other by multiple routes. Each computer should be able to reach others by at least two and preferably three physically independent paths. The routing should not be done at hubs, but at points of origin by inserting into each message destination-seeking instructions. The traditional way to connect people, such as in the telephone system, linked dumb and low cost handsets with very expensive and enormously smart central switches. In web networking, the network is passive and the switches are cheap while the messages and the stations are very intelligent.

Network stations should be treated as equals and not as separate classes of superior "clients" attended by inferior "servers" because the stations are now supercomputers. These distinctions are not just a linguistic quibble. They are a matter of distinction that are reflected in how network privileges and network organizations are put together.

Web networking supports cooperation among groups that organize and dissolve rapidly. It could be design engineers on separate continents reaching agreement on the layout of a circuit board. It could be an infantry commander coordinating close air and artillery actions. It could be working out details of a purchase with a stock broker. It could be an act as simple as placing an order for merchandise. Who will talk to whom, with what device, over what telecommunications link, is unpredictable and therefore cannot be specified in advance in the same way as you would design structural members of a building.

The fundamental premise behind web networking is that regardless of the amount of automation involved in a transaction, there is always a human being who will be accountable for what happens. Web networking is not only a matter of software design, but also a refection of managerial practices how to handle exceptions, errors, security, and responsibility for data integrity. The politics of web networking is a reflection of how an organization views relationships among employees, customers, and suppliers. The master-slave, hub-spoke configuration enforces subordination and centralization of knowledge and control. This form is medieval, authoritarian, and totalitarian. Peer-to-peer computing over web networks does not in itself guarantee cooperation, but surely makes it possible. It is egalitarian, with all of its faults and freedom to engage in wasteful foolishness."

-- Paul Strassmann, 1995, "The Politics of Information Management". Paul was the former CIO of Xerox, General Foods, the U.S. Department of Defence, and NASA.

Identity federation rumblings

Lots of grousing about the new OASIS WSFED technical committee & submission. See Tim Bray, also some scathing board-level rebuttals that he links to.

In simple terms, it's about getting WS-Federation ratified as an OASIS standard. Which is basically a wrapper & message exchange protocol for federated identity asssertions -- though based on the token exchange model defined in WS-Trust.

Incidentally, this is what SAML 2.0 does - it's a wrapper and message exchange protocol for security assertions whose integrity is ensured based on some kind of trusted token, whether an SSL shared secret, or X.509 public key signature, or Kerberos ticket, etc. SAML 2.0 also includes specs for basic token exchange that are disjoint from WS-Trust.

WS-Federation, of course supports SAML 2.0, where in that case, it's a wrapper-over-a-wrapper-over-a-token (WS-Fed -> SAML 2.0 -> trusted token) . I'll note that SAML 2.0 is an OASIS standard and WS-Trust so far is not ratified as such.

This is standards warfare at its finest. Vendors jockey for position, some play both sides to maintain neutrality, but in the end, interoperability suffers, as efforts are spread thin. The WS-TrainWreck is entertaining, it feels like the days when people just started realizing that many CORBAservices were unimplementable and the only ones worth using & testing against were based on the most popular ORB at the time (usually IONA's).

I hope we can get back to the business of enabling interoperabilty some day soon. My only solace in this debacle is that it makes every enterprise software vendor look near-equally silly.

About this Archive

This page is an archive of entries from April 2007 listed from newest to oldest.

March 2007 is the previous archive.

May 2007 is the next archive.

Find recent content on the main index or look in the archives to find all content.

About Me
(C) 2003-2010 Stuart Charlton

Blogroll on Bloglines

Disclaimer: All opinions expressed in this blog are my own, and are not necessarily shared by my employer or any other organization I am affiliated with.