It didn't come through distributed objects and through SOAP (yet), but components and services are already giant mainstream consumer-facing successes. Components, the notion of reusing units of coded behavior in multiple applications, did succeed ubiquitously: the components in web browsers are reused again and again through HTML tags, and tags are also successful components reused in the three main server page technologies. Services, the notion of reusing network endpoints to reuse the same behavior in multiple applications, is also succeeding in a big way: through RSS and portals.

It could be that mainstream success is irrelevant to the contexts in which many of us work. Maybe it really doesn't matter.

It could also be that component-oriented and service-oriented technologies have gone mainstream in a way that is not attractive to many of us engineers, perhaps because the reality is too low-tech, or perhaps because the proposed alternatives (heavyweight distributed object technologies, infinitely extensible services technologies) are more intellectually tantalizing and a great deal more powerful. But it is interesting to step out of engineering mode, step out of the academic hall or out of the enterprise, and look at how these two much-lauded areas have touched the rest of the world where apparently the power and infinite extensibility can be sacrificed.

EJB and CORBA and other distributed object technologies are great successes in the enterprise, where they address a minority set of cases but where those minority cases are also the most critical (and most financially lucrative) to address. EJB wasn't meant for the masses; it wasn't even meant to be used in a majority of J2EE applications. It was meant to address that minority of cases that are also the most mission-critical and expensive. Similarly, SOAP and the elements of the WS-I Basic Profile are excellent tools for integration and for creating next-generation workflows across enterprises and extranets.

But neither set of technologies entirely defines component-oriented technology or service-oriented technology. I am not knocking EJB or distributed objects at all; heck, I built an EJB server (JRun) and at one point served on the EJB Expert Group through the JCP. I've also built products based on CORBA and even .NET Remoting. I'm not knocking it, and I'm also not focusing on its particular niche just now.

Cedric Beust makes an excellent argument that components have succeeded in the J2EE-dominated enterprise in a way that most of its users do not perceive. It's an interesting point, but I think there's an even more pervasive example outside of the enterprise: Simple and ubiquitous web browser widgets exposed through simple tags.

Some argue that tags are not components (engineers have a hard time agreeing on what components and services actually are even in the presence of standards that supposedly resolve semantic differences). To split hairs, its the output that the tags produce that is the component; that is, it's the HTML table, the text box, the password field, the form, the image, the data grid that are the components and reused across web applications from Amazon to Google to Slashdot to Ebay. The tags are the application programmer's interface into these components, and expose configurable properties (via attributes and nested elements) on the components. To craft custom components that others can reuse, a developer creates custom tags in JSP, ASP, or whatever server page technology tickles his fancy. The entire application is not just components stacked against components, of course, and glue and bindings between them are often needed. Scripting languages are commonly used for this. And there I sense a digression that I will sidestep.

Just as components promise reuse of code in diverse applications, services promise reuse of network endpoints in multiple applications. Components can obviously be used to build services, though some confused people seem to think that services and components are competitive and mutually-exclusive. This makes no sense. Give a set of components that comprise an application or subsystem -- not just an object, as in distributed component technologies, but an interface into a domain model or an interface into an entire application -- a network endpoint, and it is a web service. Of course, not all services are web services, and I'm simplifying a bit. But it is a useful thing, in many cases, to create a single interface into a subsystem and not reuse the code used to create it so much as instead allow diverse applications to reuse that single interface by reusing the network route to it.

Service-oriented technologies are a mainstream success first with content rather than application behaviors. That is, messages containing content are flung around services more than are rpc-style invocations. Portals are an example of this, as are RSS feeds in and out of portals, and workflow applications and enterprise technologies such as BPEL and ebMS (both of which actually do use SOAP and will therefore conform to the typical enterprise engineer's more narrow definition of web services) are also examples. It could probably be argued that any SOAP web service using the document/literal style -- skipping .NET's odd literal wrapped style for a moment -- adheres to this as well. Ok, another digression is gingerly sidestepped.

For every one public SOAP service available on XMethods, or just generally available out on the web, I would hazard a guess that there are maybe 600 weblogs that make use of RSS (for subscribing) and XML-RPC (for publishing). Even the most notable set of public commercial SOAP web services, those produced and maintained by Amazon, apparently see less usage than the simpler and more bandwidth-friendly REST API that Amazon also maintains. And portal servers -- which, along with integration servers, are practically the only horizontal J2EE software that big enterprise vendors are making much money on these days -- breathe RSS as well. So it's not SOAP-based services, and it's not extensible, but these XML-RPC and RSS services are giant hits in the real world, and increasingly in the enterprise as well.

Just as I noted earlier that I wasn't meaning to knock EJB, I am also not knocking SOAP. I spent a good deal of time this past year adding SOAP, WSDL, and XML Schema support to various Macromedia Flash products, and am enthusiastic about SOAP-based services. I'm merely making observations about service-oriented usage in the mainstream, and pointing out that the success of web services architectures do not depend entirely on adoption of SOAP and WSDL.

I suppose service-oriented technologies could go the way of the mainstream web, and start with content messaging and eventually grow to encompass application delivery and general rpc. Many believe that when services begin delivering application behavior rather than mostly content, the initial applications will come through instant messaging service endpoints rather than through anything like hosted SOAP services. I think it would be interesting to see the IM services be exploited for pushing data to other systems rather than just for person-to-person chatting. Yet another digression, my apologies.

So things didn't turn out (so far) exactly as a lot of us engineers planned except in certain corners of the enterprise, and so there are some silly and occasionally annoying problems with the way things did turn out for the masses which makes that mainstream reality less interesting the enterprise realities. But still, it seems to me that while we smart folks were occupied with more interesting designs for these two areas, first component-oriented and lately service-oriented technologies have been hanging out with our fathers-in-law, or with our daughters, out in the non-techie real world, and have managed to go mainstream.