Phew. Now I am confused. I get the provider and consumer part. A provider provides a service in response to a request from a consumer, which in turn consumes that request. (Maybe the lunch analogy actually is a good one–we really are consuming things here.) Loosely coupled apparently means joined for a particular process but not necessarily joined at the hip. I have seen the term point-to-point architecture used in contrast to loosely coupled–neither of which makes any sense. If a traditional desktop application requires a certain module or library to function, then it would be considered tightly coupled. If a Web application requires a certain module to function, is it not still tightly coupled to that module? Apparently not. If the provider and consumer are on a network and are able to work together, they are called loosely coupled. These distinctions are highly semantic and highly confusing.

And then there is: "A service is a unit of work done by a service provider to achieve desired end results for a service customer." I think I would prefer to read that in the original Latin. Let me translate by example. Calling a function on a remote module to connect to a database is not a service in this context. Calling a function that provides the number of business auto applications underwritten today is. SOA provides business services for consumption. In other words, SOA is an architecture based upon loosely coupled business services. Consider this in opposition to Web services. In the developer world, we typically deal with Web services. According to the World Wide Web Consortium (W3C), a Web service is a software system designed to support interoperable machine-to-machine interaction over a network. In the real world, this generally means Java Web services or .NET.

If service-oriented architecture were just about software design, then it really could be considered marketing hype about Web services. In fact, the standards SOA is built on–XML, HTTP, SOAP, WSDL, and UDDI–also are the characteristics of Web service components. In theory, SOA architectures can be abstracted away from the actual implementation. In practice, they often are one and the same.

At National Underwriter, we have created a number of .NET modules whose purpose is to facilitate communication between an enterprise document management system and an outward-facing Web content management system. This system consists of a number of modules that expose perhaps 75 methods that can be called across a network. We used XML, SOAP, and WSDL in implementing these modules. They call upon the APIs of other off-the-shelf .NET modules. One would think we have created applications that conform to a service-oriented architecture. We have providers and consumers of data and information; bindings are established at run time. The modules are loosely connected. Maybe it is time to put SOA Specialist on my resume. Sounds good to me. Whoops. I forgot about the business services–the services I am exposing are programming services. The SOA linchpin is the services distinction. The problem is I am not sure whether the distinction lies on the consumer side or the provider side.

Consider a very simple Web application. A consumer lands on a Web page with the intention of submitting a claim for his automobile insurance. He enters his log-in information via HTTPS. That information is passed to a Web services module that validates the information and creates a client-side session cookie. The user is granted access to a claims submission area where he is led through a series of Web pages to submit his claim. Each succeeding page is based upon information processed by a remote module and passed back to the Web server and hence to the client Web browser. The whole process uses dozens of remote procedure calls across the network to different modules and servers. Taken as whole, all those methods invoked in this process comprise a process named "submitting a claim." And submitting a claim surely could be considered a business service. Right. But is this SOA? I don't know.

Since we created all that claims-submission technology for our external customers, we certainly can reuse it for internal consumption. Create a thin client or Web client for the corporate network or intranet, and bang, you have another claims submission app. But where does the SOA enter into this equation? We have been creating reusable code and code modules for as long I can remember. It is not as if we are exposing a method called "submit a claims application" and invoking that. The client app still needs to accomplish all those procedure calls in order to walk the process–dare I say choreograph the service?

Let's face it, SOA is a very high-level abstraction, probably better suited to the boardroom than the IT lab. One method of quantifying SOA that looks promising is business process execution language (BPEL). According to the IBM information center, "BPEL is an XML-based language for the formal specification of business processes and business interaction protocols. BPEL extends the Web services interaction model and enables it to support business transactions. It is the result of a cross-company initiative between IBM, BEA, and Microsoft to develop a universally supported process-related language."

How would this work? I would envision business decisions-makers working with what we used to call systems analysts to lay out their business needs. The systems analysts then would use BPEL or UML to translate the business needs into a high-level process of data flow and state. That then could be flipped over to the software architects who would translate that into a process flow that could be interpreted and coded.

Widespread ubiquitous desktop computing really created the need for reusable code. The Web made that need an imperative. When we all were using green screens hooked to the mainframe, the code was in one place anyway. Desktop GUIs were based upon commonly used code in libraries that could be accessed by any hack who understood the API. Those common libraries quickly evolved to remote calls across process, then across machines, and then across networks. Good programmers always have coded for reusability. The transition from desktop applications to Web service applications just meant we exposed methods and properties in new ways. Just the other day we were debugging a cantankerous process, and as I watched the team step through the procedure, I was struck by how little things had changed from when we were doing the same thing in a C DLL instead of C# Web module. The more things change, the more they stay the same.

Perhaps there is some value in creating high-level services. Visual Basic abstracted the Windows API for a whole generation of wannabes in the '90s. Maybe we should set up SOA shops and create SOA modules that expose only business processes. Things such as "update customer information," "process claim for payment," and "underwrite this client" would be methods using SOAP messaging. Then a whole new generation of wannabes could create interfaces to those applications using "software development tools." Old-school software developers could retreat into caves where they would hold the real keys to the kingdom and thus the ultimate power. More abstraction actually provides job security to those who know how it really works. There is a distinct advantage in being one of the guys who still can build the tool in a world that doesn't want to know.

Distributed, interface agnostic, code agnostic, and vendor agnostic applications are the way we all do business now. I don't know that we need new buzzwords to make us better software developers. I do know piling layers of abstraction on what we do will cost more in the short term as we wade through the morass of these new abstractions. Maybe it will pay off in the long term. Maybe not. Anyway, let me know how your meeting on governance works out.