Section 2.1. Milestones of Enterprise Computing

2.1. Milestones of Enterprise Computing

The term "service" has been present in commercial computing for a long time and has been used in many different ways. Today, for example, we find large companies, such as IBM, promoting the concept of "services on demand." At the beginning of the new century, the term "Web services" became extremely popular, although it has often been used to refer to very different computing concepts. Some people use it to refer to application services delivered to human users over the Web, like in the popular salesforce.com application. Other people use the term "Web services" to refer to application modules made accessible to other applications over the Internet through XML-based protocols.

Because of the many different ways in which the term "service" has been used over the years in the IT industry, it is necessary to define more precisely how we use it in this book. However, before looking at a more formal, technology-oriented definition in Chapter 4, "Service-Oriented Architectures," we will look at a more generic definition that better suits the purpose of this chapter, which is examining the roots of "our" understanding of services.

The Merriam Webster's Dictionary gives various definitions for the term "service," including "useful labor that does not produce a tangible commodity" and "a facility supplying some public demand."^[1] In this book, the term "service" takes its meaning from these definitions. It denotes some meaningful activity that a computer program performs on request for another computer program. Or, in more technical terms, a service is a remotely accessible, self-contained application module. Application frontends are making these services accessible to human users (see Figure 2-1). Often, the terms "client" and "server" are used synonymously for "service consumer" and "service provider," respectively.

^[1] http://www.m-w.com.

Figure 2-1. Our understanding of the term service: A service provider (commonly a remote server) performs some task at the request of a service consumer (the client).

The services covered in this book provide abstraction from a lot of their technical details, including location and discovery. Typically, our services provide business functionality, as opposed to technical functionality. Consistent with the definition from Merriam Webster's Dictionary, our services are not designed for one specific customer, but instead they are "a facility supplying some public demand"they provide a functionality that is reusable in different applications. The cost effectiveness will depend strongly on the number of different customers a service has, that is, the level of reuse that can be achieved.

A concrete implementation of an SOA provides service consumers with seamless access to the different services available in it. Thus, after a service consumer is "wired" into the instance of the SOAafter the "ring tone" of the SOA is availableusage of the services is seamless and transparent. However, Chapter 1 said that an SOA is an architecture per se and not a service bus or any other specific middleware, and therefore, it describes structure, not concrete technology. Consequently, instances of SOAs might take very different technical shapes and forms in different enterprises.

A crucial factor in the development of services as we understand them in the context of this book is the quest for the right degree of abstraction. Ultimately, a service encapsulates some activity of a certain complexity. Using a service makes the world more convenient for the service consumer. Consequently, an appropriate interaction pattern must exist between the service provider and service consumer. Given the analogy of the telephone network as the service infrastructure, services can be anything from hectic chatter to concise and focused conversation. They can also include some form of telephone conference, answering machine, or call redirection. In the remainder of this book, you will notice surprising similarities between the service concept and the telephone analogy.

It is interesting to notice that the service model, as it is defined in this book, has been preceded by many technologies and technical concepts in the last 30 years that shared many of the same underlying ideas and concepts. For example, look at the creation of reusable business functions on mainframe computers. Small computer networks created a fertile ground for service-related innovations, most notably the creation of remote procedure calls. Component-based development and object orientation promoted interface-driven design paradigms. Combinations of these concepts spawned platforms for distributed computing. At the same time, relational database development progressed rapidly, creating reliable data stores for enterprises. Business functionality left the mainframes and moved to one of several distributed paradigms. In the 1980s, packaged business solutions became available to a wide range of functional areas and industries. By 1995, the World Wide Web offered an extremely simple yet extremely successful service: the provision of content over a global network. The same network infrastructure is used today to enable interaction between remote computer systems through Internet protocols such as ebXML and SOAP.

The roots of service-orientation can be found in three different areas: programming paradigms, distribution technology, and business computing. The development of different programming language paradigms has not only contributed to the implementation platform for the different elements of an SOA but also has influenced the interfacing techniques used in an SOA, as well as the interaction patterns that are employed between service providers and service consumers. Many of the concepts originally found in programming languages have also made their way into the distribution technology that is presently used to offer remote access to services provided by different applications on different technical platforms. Finally, and maybe most importantly, the evolution of business computing has resulted in a large number of proprietary as well as packaged applications (see Figure 2-2) such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and Supply Chain Management (SCM), which today are providing the contentthe data and the business logicthat brings an enterprise SOA to life. Because of the closeness of services to concrete business functionality, service-orientation has the potential to become the first paradigm that truly brings technology and business together on a level where people from both sides can equally understand and talk about the underlying concepts.

Figure 2-2. The long history of programming languages, distribution technology, and business computing has influenced the development of a new paradigm, called service-orientation.