FIGURE 7.15 The Domain

Service Provider pattern.

By our definition, a domain service provider is a domain-specific conceptual unit within a large distributed application system. A domain service provider represents business logic in a way that encapsulates the reproducible and interrelated interactions of an application context with the pertaining materials.

Domain service providers are addressed by application components or other domain service providers and respond by supplying their services. To provide a service, they use the materials they manage.

Domain service providers are implemented so that the specific way these services are rendered and which interaction model is used to present the results at a user inter-face remains open.

If domain service providers are not oriented to a specific presentation and handling or interface technology, then a number of different sales channels could package the ser-vices and present them differently, depending on the customer type and technology.

Different service providers could each support various workplace types and other services.

EXAMPLE

In our bank example, assume that there is a central service provider, AccountManagement. From his or her desktop system, an account manager could request portfolio information for a customer from this service provider. An account man-ager working in the field, for example, selling a new insurance package offered by the bank, could request account information for the same customer on a laptop application in an ftp (file transfer) session. In addition, this customer uses the AccountManagement service provider in a Web browser over the Internet, for example, to view account state-ments and make paystate-ments from the account.

In this example, the domain service provider, AccountManagement, supports a domain-specific functionality jointly used by different workplace types and frontend technologies.

BACKGROUND: DOMAINSERVICEPROVIDERS

Modern technologies have had a major impact on how organizations handle their busi-ness as they open up different sales channels to reach customers. Many companies offer their products online, and electronic commerce is regaining its pace, especially in the B2B (business to business) sector. A major change can be observed, particularly in the ser-vice industry, where companies expand their activities by adding serser-vices on demand, call centers, or mobile field services. Currently, many of these service forms are still found in isolation, somewhat blocking integrated services at customer sites, because the underlying applications are primarily linked on a data level rather than over con-ceptually higher business transactions. For example, many database applications are based on isolated data for accounts, deposits, contracts, and other data pertaining in some way to a customer, but a general concept customer with links to all related entities is missing.

The Internet allows people to compare products and services directly. Potential customers can obtain information about prices and services of different vendors quickly from their homes. The Internet also allows competing vendors, including vendors from different industries, to penetrate the core businesses of organizations. This means that these organizations feel a need to be present in this medium. The reason is the increas-ing trend that open markets and new technologies dissolve narrow industry boundaries.

The Bank example

For example, many insurance companies have started offering bank services, while banks have expanded into the insurance business, and do-it-yourself companies offer travel packages.

Though this change challenges many traditional organizations, it offers a chance to bundle different services in a few concentrated sales or service points.

The downside is that most currently deployed application systems are too limited to support these new business trends. In addition, many host-based applications have reached the point where they can no longer be maintained or upgraded. While many workplace applications have been replaced by other technologies or implementations, we can see the same happening in an attempt to support new sales channels.

Unfortunately, there are not many integrated applications to support these organi-zations in their efforts to grab these business opportunities. Domain functionality is developed in many and different ways. If you find some degree of domain-specific inte-gration, it is mostly found on the level of the host database and data-exchange.

Multiple implementations of application logic is the central problem that new technologies must overcome. This problem is further aggravated by a technical problem, because most new applications are implemented as client-server systems.

These systems are mostly structured on the basis of the so-called three-layer architec-ture (see Section 9.3.6). This architecarchitec-ture suggests an integration of the functions or applications involved on the data level. In summary, there is a lack of domain-specific integration.

This chapter introduces domain service providers as a relatively new concept within the T&M approach. Note that the concept of domain service providers com-plements the other concepts rather than replaces it.

DISCUSSION: DOMAINSERVICEPROVIDER

To ensure a uniform image toward the customer, coordinated sales activities, and a continuous customer service, we have to integrate all systems used in an application domain on a high domain-specific level. Regardless of their workplaces and tasks, all users should be able to handle their activities, such as business transactions, services, customer files, or product sales and support, in one system. Otherwise, we won’t be able to open up application systems for both users and business partners. Domain services represent this high level of cooperation and common access to the system. Based on the principle of structural similarity, they encapsulate domain-specific tasks and objects and their distribution as independent processes and elements.

Domain service providers are “behind” all application system frontends and chan-nels, allowing us to represent a uniform service concept and a uniform customer-oriented image. Note that all these different sales channels complement each other.

Regardless of whether customers contact their bank over online banking or in person, they will always see their accounts reflecting past and current bank relationships and obtain end-to-end service.

DISCUSSION: COMMONWORKOBJECTCOLLECTIONS

We often find jointly used collections of objects, such as customer files, in central archives or filing systems. In most application domains, objects are constantly needed at different workplaces. On the functional level, the only important characteristic of this jointly used collection is that it can accept and return materials.

Let’s study this issue in the context of an example, using the JWAM registry. The JWAM registry represents a central location to manage and register documents as they are filed or retrieved by users, without taking any further specialization or additions into account.

We define the following T&M design guideline:

A more or less generic container interface does not qualify a domain-specific collection as a domain service provider, because there is no domain-specific han-dling of materials.

DISCUSSION: DOMAINSERVICEPROVIDERS ANDRESOURCES

Materials are often handled and checked in a standardized form. These domain-specific functions are independent of work relationships, where they are used in a specific man-ner. The important thing to understand is that this is where domain functionality and a collection of materials meet. Such basic services can be integrated either in existing workplace concepts or by accessing other service components.

Even if a central task of a domain service provider consists in permanently storing materials, it is not a pure material collection. In addition, the domain service provider monitors the entire life cycle of a material. This means that we can add application logic to creating, modifying, and deleting operations. The application developer can then concentrate on the domain-specific use of materials, without having to bother about a database interface.

Domain service providers of this type normally offer services like “use material B to do activity A,” “check whether material A meets property B,” “use properties A, B, C to create a material,” or “delete material A.”

It appears meaningful for this type of service provider to prevent the direct dis-pense of copies of managed materials to clients or to accept modified materials from clients. Instead, the service provider offers all changes to materials as operations at its interface, in particular when these changes are highly atomic, so that several clients can change materials concurrently. The reason is that all these dispensed copies may cause a locking problem, or updates may get overwritten before they can be saved.

A domain service provider is stateful, because it serves as a storage location for objects representing the domain services of the application. Toward the outside, the service provider changes its state as soon as a material it manages is modified.

Independent of the internal construction, a domain service provider appears stateful, because a change to a material causes probing operations on the service to produce dif-ferent results.

Consider this example. A car rental company manages its car pool. When the market situation for used cars changes, then the depreciation rates for individual car types have to be revised.

We define the following T&M design guideline:

The central domain-related management of material collections is a good argument in favor of a domain service provider, because it would encapsulate a material collection with the domain-specific interactions.

Example

Design guideline

Example

Design guideline

DISCUSSION: DOMAINSERVICEPROVIDERS ANDBUSINESSTRANSACTIONS

Many companies supply their products and services in the form of business cases or transactions, where such a business transaction often “visits” several departments. The drawback of traditional transaction processing is that it is hard to follow up on each of the transactions as they flow between workplaces. Centralized electronic transaction management is normally used to solve this problem. This means that each active trans-action is either processed at a defined workplace or stored in a central repository.

Finished business transactions can be archived or dissolved in subsets stored in differ-ent locations.

A domain service provider can manage information about complex relationships and the implications of business transactions for clients, facilitating their work in the application domain. It encapsulates potential sequences of work steps and responsibil-ities, representing a case or transaction by a material, such as in the form of routing slips.

Business transactions can be efficiently represented by domain service providers, especially if we add the model of a user session. To activate a transaction, the user can then select the domain service, which will “remember” the user until the transaction is complete. In this case, we could do without representation of a transaction by a material in the usage model.

Service providers that encapsulate business transactions could also be used to store and retrieve materials. This means that the service provider’s task would partly over-lap with a domain-specific resources management. However, a transaction service provider often manages materials while a transaction is pending, passing control to the resources management service provider when the transaction is closed.

Let’s look at a practical example. A new health insurance contract flows across several departments or stations. More specifically, it arrives in the organization in the form of an application. Later, the company requests specific documents from the insured and his or her physician. Eventually, the contract is signed, posted for regular payment of the premium, and the payments by the insured are posted to an account.

During the life cycle of this contract, the insured can call and request information about a current business transaction.

We define the following design T&M design guideline:

Business transactions handled by several actors in a standardized from, and which have to be located while they are active, can be easily managed by a domain service provider.

These transactions are often represented as a domain-specific collection of mate-rials, such as folders with routing slips, and they can be managed and processed in a specified manner.

DISCUSSION: DOMAINSERVICEPROVIDERS ANDCOLLECTIONS OFFUNCTIONS

Some domain-specific functions or calculations are recurring or repeatedly required in the activities of an organization. Normally, there is an entire collection of interrelated functions. These functions are independent of a workplace. They correspond to the mathematical notion of a function, because they receive all data required as values for call parameters, and return a value as a result of that function.

Example

Design guideline