Getting a handle on Web services
With procedural programming, data structures refer to each other and routines are created to manipulate the data structures. As the complexity of programs increases, so does the number of routines and data structures operating on each other.
So with procedural programming, complex programs can become increasingly difficult to maintain and support.
Then, there’s object-oriented programming (OOP), which offers a greater level of sophistication to developers. With OOP, objects contain both state and behaviour, allowing a single entity to describe what it is and what it can do. And the objects have relationships to each other. Also, OOP introduced such concepts as encapsulation and polymorphism. OOP made complex programs easier to write, maintain, and support.
Now service-oriented programming (SOP) has entered the fray with even more sophistication. Developing applications using SOP encourages a powerfully clean separation of developer concerns, increased reuse, fewer defects, and increased ability to meet future needs. In the same manner that OOP builds on procedural programming, SOP builds on object-oriented programming.
A service is a core piece of business logic that is protocol independent, location agnostic, and contains no user state. Services don’t contain presentation logic, nor do they contain logic to integrate with data-tier resources, such as a database. Services focus exclusively on solving business domain problems.
Services are very loosely coupled with other components of an application. They’re protocol independent, allowing for the same service to be accessed in multiple ways, and coarse-grained. This allows the service to perform its business logic and return the result in a single call. A good example of this would be a service named getAccounts, which returns the information for all specified bank accounts for a given user.
Services typically rely on configuration data to determine things, such as which data-tier integration module to call. But configuration data for individual users is typically never stored. For example, services shouldn’t store user state beyond a single request. This enables services to be multi-user-safe (ie, a single instance of a service can be called simultaneously for many users).
Applications are typically described by what they do, not necessarily by what they are or what they contain. For this reason, it’s much more straightforward to describe an application using verbs as opposed to nouns. In contrast, OOP establishes itself on the basis of describing objects, and the state and behaviour they contain.
In most distributed component frameworks, such as J2EE’s Enterprise JavaBeans, the primary entities that are intended for business logic are based on an OOP component. Since objects define a thing and not an action, an impedance mismatch can occur when attempting to encapsulate what a component does as opposed to what a component is.
In SOP, an application is described much more naturally. Each function of the application that can be verbalised will likely be a candidate for a service.
Typically there are five tiers in an enterprise application:
- Client tier renders the user interface (UI) of an application. The client could be an application running on a PC, a browser connected to the Internet, a cell phone, or a PDA.
- Presentation tier is responsible for receiving requests from a client, interpreting them, and then forwarding them to the business tier for processing. The presentation tier then packages the response and sends it to the client.
- Business tier should be the focus of any enterprise system and is the domain that should contain all business logic for an enterprise. Business logic should be exposed as loosely coupled services that can be reused as parts of multiple diverse applications.
- Integration tier contains software modules that connect to external resources to get and output data. External resources can be databases, directory services, Web service providers, file systems, etc.
- Resource tier contains repositories of data such as a database or another enterprise system such as an ERP, CRM, or a Web service provider.
These five tiers are logical constructs in nature. Where they reside physically is typically a deployment issue. For example, in a small application, the presentation, business, and integration tiers might all reside on a single machine. In more complex applications they will be deployed across multiple machines. Similarly, when an application’s popularity increases to the point that it needs additional resources, these logical tiers can be separated physically to provide additional computing power.
A service-oriented approach to enterprise application development encourages increased reuse of major business components. With a service-oriented development model, application development consists of combining one or more business services together to form a cohesive unit. This approach has the potential to bring about a faster time-to-market, fewer bugs, and lower maintenance costs.
—Jeff Hanson
Shouldn't you change 'Microsoft has changed' to 'Microsoft has to change'? A small but great difference, imho...