I don't know about you, but I am getting a little tired of the apparent need within the developer community to create new buzzwords and terminology to describe what we do. When I say the developer community, I am talking about marketing geeks who work for software companies and the journalists who write about these wonderful new "architectures." Real developers understand the whole "call a routine–return a result" process without needing to name it. The term that really is sticking in my craw these days is service-oriented architecture (SOA).

As I flip through the countless software and IT magazines I receive, I see article after article on how to implement SOA. And, of course, you can't discuss SOA without getting into such esoterica as object-oriented analysis and design (OOAD), enterprise architecture (EA) frameworks, and business process modeling (BPM). If you truly are one of the cognoscenti, you would focus on service-oriented analysis and design (SOAD) instead of the humble SOA. I recently saw a posting on an SOA blog likening this terminology to "food-oriented lunch."

What initially attracted me to information technology was the simple elegance of not only the process but the theory behind the process. The closer to the machine I could get, the happier I was. It was lot more fun to write assembly code on a mainframe than run a COBOL batch. The more we abstract the process, the further we get from understanding what we are doing. I often suspect the evangelists for all these high-level abstractions are actually guys who never could get into the code but were able to find a life in obfuscation. Consider the following terms, all of which I encountered in an introduction to SOA: service choreography, service bus middleware pattern, business process governance. The day I schedule a meeting with my dev team and announce we are going to discuss governance is the day I lose my last bit of credibility. I was scanning job postings and resumes on an online techie service recently. In a major metropolitan area, there were 2,619 tech jobs posted–two jobs specified a need for experience with service-oriented architecture. J2EE appeared in more than 200 postings. It seems like the guys in the trenches care more about skill sets than mind-sets.

Since we got this far, we might as well take a look under the covers to see what SOA is all about. I will offer some further definitions, but to get us started, I picked the first one to rise to the top on a Google search. This is from XML.COM (http://Webservices.xml.com/pub/a/ws/2003/09/30/soa.html): "SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners."

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.

Special Reports /

In Name Only

Related Stories

Recommended For You