Today's software industry is moving fast to supply innovative technologies, new standards, and early customer case studies targeted at fulfilling the vision of Web services. But as these products, standards, and customers emerge, it is now time to move beyond using the simple term Web services - it really misrepresents what is starting to take shape in today's enterprise, the emergence of the enterprise service-based architecture.

A Changing Landscape
Without a doubt, Web services are real in today's enterprise, primarily through the emergence and subsequent adoption of three important, agreed-upon technologies: SOAP, XML, and WSDL, considered the foundation for enabling Web services. However, if we look deeper inside the world of IT, we find other well-established and emerging technologies like Java, Enterprise JavaBeans, JMS, .NET, and CORBA. These technologies further establish the bedrock for a much more important phenomenon that is emerging - an enterprise service-based architecture that is built upon the foundation technologies of Web services. Java, Enterprise JavaBeans, CORBA, and JMS, in combination with SOAP, XML, and WSDL, are enabling this new enterprise service-based architecture. It's now time for the industry to stop focusing on describing and defining Web services and move toward describing and defining a service-based architecture for developing and deploying information systems. In addition, the vendor community should now focus on describing how their particular solutions fit into this new architecture and the benefits they deliver to today's enterprise information systems.

Filling in the Gaps
As enterprises begin developing an enterprise service-based architecture, much of their existing legacy code will need to be accessed as services to leverage the underpinnings of this new architecture. Existing code may have been built using Java or Enterprise JavaBeans, or invoked using message-based systems. The challenge is in enabling the chunks of software in a service-based architecture when you have to deal with different protocols or are concerned about the performance implications of interfacing, for example, your Enterprise JavaBeans through SOAP versus through a native call to the bean.

The good news is that development environments like Visual Studio and BEA WebLogic Workshop allow the rapid construction of Web services for new and existing code. In fact, many vendors are doing quite a bit to expose critical functional components of their solutions as Web services. All you have to do is go to Google and type in the name of your software vendor and the term "Web services," and you will likely get a good list of links taking you to information on their Web services capabilities. In addition, innovators from many areas of the industry have come together to build an infrastructure for invoking services under a promising project that is part of the Apache Software Foundation, WSIF (Web Services Invocation Framework). In a nutshell, WSIF is a Java-based API that allows your client code to invoke WSDL-based service through a layer of abstraction rather than natively through SOAP. The abstractions are the pieces of WSDL that include the port types, operations, and message conversations that don't refer to the actual protocols being used. According to the Apache WSIF site, "the abstract invocations work because they are backed up by protocol-specific pieces of code called providers. A provider is what conducts the actual message exchanges according to the specifics of a particular protocol - for example, the SOAP provider that is packaged with WSIF uses a specific SOAP engine like Axis to do the real work. The decoupling of the abstract invocation from the real provider that does the work results in a flexible programming model that allows dynamic invocation, late binding, and clients being unaware of large-scale changes to services - such as service migration, change of protocols, etc.

"WSIF also allows new providers to be registered dynamically, so you could enhance your client's capability without ever having to recompile its code or redeploy it." Furthermore, according to the WSIF site, "using WSIF, WSDL can become the centerpiece of an integration framework for accessing software running on diverse platforms and using widely varying protocols. The only precondition is that you need to describe your software using WSDL, and include in its description a binding that your client's WSIF framework has a provider for. WSIF defines and comes packaged with providers for local Java, EJB, JMS, and JCA protocols. That means you can define an EJB or a JMS-accessible service directly as a WSDL binding and access it transparently using WSIF, using the same API you would for a SOAP service or even a local Java class."

Combine the functionality of WSIF with the fact that many solutions are available for wrapping existing code and exposing it as Web services, and we begin to see that we have a world in which we're able to interact with the services in an abstracted model that is protocol independent. WSIF efforts must now expand on the number of providers. Currently providers exist for JCA, EJB, and JMS. It is hoped that the list of providers will expand over time and that we will see WSIF supported in other enterprise software solutions.

A New Server Emerges to Support Service-Based Architectures
Popularized by the emergence of technologies like Java and .NET - along with the emergence of the enterprise application server from companies like IBM, Microsoft, BEA, Novell, and Oracle - over the years, many enterprises have shifted the focus of their development efforts from a client-server architecture to an application server-centric architecture. Today, however, we are starting to see the emergence of a new class of server platforms that will help the enterprise move from a server-centric architecture to a service-based architecture; what I call the enterprise service platform. Already, companies like IBM and BEA are rapidly expanding the capabilities of their application servers and surrounding tools in order to support the creation of an enterprise service platform. The beauty of this expansion is that enterprises with existing application servers will be able to leverage their existing solutions, skills, and knowledge, and begin to take advantage of the new capabilities of these enterprise service platforms to move them quickly toward service-based architectures.

Expanding Support for the Service-Based Architecture
Further evidence of the emergence of this new enterprise service platform and service-based architecture is the wide spectrum of independent software vendors, ranging from start-ups to specialists, that are filling the gap in functionality by developing supporting infrastructure to the emerging service platform. Two particularly busy areas for opportunistic entrepreneurs are service-based management and service-based business process management systems.

One area of focus inside today's enterprise is that of streamlining various business processes with the objective of reducing latency in the business in order to respond more rapidly to increasing customer and partner demands and to become more operationally efficient. All this comes with a drive toward achieving further cost reductions and profitability in the business. Combine this with the emergence of industry regulations like HIPPA and Basel, and the topic of optimized business processes is bubbling up to the boardroom in today's enterprises.

This renewed interest in business process optimization will go far in pushing an enterprise toward a serviced-based architecture. In fact, industry analyst firm ZapThink is already calling this "Service-Oriented Process" and claims it will be an $8.3 billion market by 2008 and will drive 70% of Web services implementations. Although this is a bold claim, service-based architectures will certainly require that a business process manager be available to the enterprise to effectively orchestrate the services in the context of the overall business process. Service-based architectures will go a long way in simplifying how services are orchestrated; in fact, many believe that we will soon see a time when business-level analysts, not IT professionals, will build, streamline, and manage the business processes within an enterprise using these service-oriented process tools.

Further enforcing the direction toward a service-based architecture driven by business processes are enterprise software vendors like SAP, Siebel, and PeopleSoft. Already these vendors are pushing service-based business processes as a way of integrating their systems with other custom or packaged applications. Siebel Systems has invested substantial dollars in a project they call Universal Application Network (UAN). The objective of UAN is to provide a core set of prebuilt business processes supported by the Business Process Execution Language (BPEL) standard to make it easier to integrate systems through the use of exposed services. The intention of UAN is to enable any business process orchestration vendor that supports BPEL to interoperate and support the UAN business processes. To enable UAN in an enterprise, the enterprise must be in the mode of moving toward an enterprise service-based architecture. The same goes for SAP and PeopleSoft. Again, as the enterprise application vendors ramp up on service-based architecture, it will be easier for enterprises to adopt components of the enterprise applications as services in the context of their overall business processes.

Once an enterprise embarks on a mission to move toward a service-based architecture, they will need to adopt a service-based management framework. Again, this is a hot spot in the area of emerging service-based solutions. The purpose of the management framework is to help the enterprise observe, organize, report, and act on the services deployed inside the enterprise, regardless of where they originated, how they are invoked, or what other services they depend on. Emerging companies like Adjoin, Actional, and Confluent, and even larger established enterprise players like HP and IBM, are all building out service-based management tools and technologies to help enterprises get control of the runtime characteristics of their services. These solutions vary in their capabilities and ability to reside inside the enterprise service-based architecture, but will certainly be part of the overall software stack needed to ensure the success of a serviced-based runtime environment.

Open Source: A Maturing Player in Enabling a Service-Based Architecture
In today's highly competitive market, there are hundreds, if not thousands, of available commercial and proprietary software vendors and system integrators that will support an enterprise initiative to move towards a service-based architecture. In addition to these commercial offerings, there is a huge wave of open source initiatives, some highly visible like Linux and JBoss, and some just getting started. The community and collaborative efforts amongst the open source efforts are powerful and moving fast and furiously to support alternative solutions to proprietary commercial service-based offerings. This certainly has the commercial software industry watching very closely. However, even commercial software vendors are getting into the game. Take IBM, for example, who is carefully straddling the fence between open source and commercial efforts around enabling the creation of a service-based architecture. IBM played a key role in the efforts around WSIF, as mentioned earlier in this article. With the rapid emergence of open source, enterprises would do well to start preparing themselves to potentially take advantage of this rich source of new and emerging technologies as they embark on a service-based architecture.

One way to approach this open source topic is to establish a team of skilled professionals whose purpose in the enterprise is to investigate and experiment with open source solutions in order to gauge whether or not the open source solution could be an alternative to a commercial offering in support of a service-based solution. However, before ever deploying an open source solution, an enterprise should also have a person or team of people developing policy and procedures, in conjunction with the company's legal department, for how open source is used, supported, and deployed within the enterprise. In fact, because it is so easy to download open source products along with fragments of open source code, it wouldn't be unusual for an enterprise to have already been injected with open source without the company knowing it.

Having good policy, processes, and practices will go a long way to control the use of open source without getting heavy handed with your developers. The licensing and use of open source is all over the board. Without this level of expertise, enterprises may put themselves at risk by not having appropriate policies.

Begin Your Initiative Now, Your Competitors Are
With major enterprise software vendors and open source efforts all pointing toward support of the emergence of enterprise service-based architecture, companies must start their efforts now or face increased competition from enterprises that jumped on the early adopter bandwagon and experienced success. I frequently like to use Kinko's as an example of a company that saw the opportunity to leverage a service-based approach to expand their business model.

Kinko's recently announced that they will be exposing a printing service as a Web service to Microsoft Word users. With the Kinko's service enabled, it is envisioned that Word users, choosing the print command, will see the standard print dialog but, in addition to seeing all the printers, they'll also see a "Print at Kinko's" option. Selecting the service will allow users to pick the Kinko's closest to their physical location in order to have the job printed at the chosen Kinko's location. I'm sure that a message will travel back to the user indicating that the print job is complete and ready to be picked up. Who knows, maybe even a map from MapQuest will be displayed showing the exact location of the Kinko's. Imagine how, by taking this approach, Kinko's would be able to expand their business model by making it very convenient for their customers to take advantage of this future service.

Expanding the concept further, imagine Kinko's interacting with a Federal Express service where the user would simply send a list of mail addresses to the Kinko's service, requesting that the final print jobs be sent to Federal Express for delivery to the specific addresses. This is quite visionary on behalf of Kinko's. With success and good user adoption, this service might serve as a "poster child" to demonstrate how, by taking a service-based approach to their business, Kinko's is able to better serve their customers and further expand their business visibility.

Today we are in the early cycle of this new service-based architecture. In the future, we will see the benefits to businesses who, like Kinko's, saw the opportunity to move to a service-based offering and expanded the capabilities of their business.