Services communicate with each other by exchanging structured information -- messages or documents (sometimes called business objects). Their capabilities are defined by interfaces declaring messages they can produce or consume, policy annotations declaring quality of service required or provided, and choreography annotations declaring behavioral constraints that must be respected in service interactions. The actual implementation is hidden from the service requester, thus SOAs are a convenient way to achieve application integration by allowing new and existing applications to be quickly combined into new contexts.
Existing applications are "adapted" to service declarations. An adapter follows the WebSphere® Business Integrator model, for example. The adapter implements the service interface and transforms messages into operation on the existing application.
All interactions between services flow through the Enterprise Service Bus (ESB). This does not mean, however, that all interactions require network communication and XML messages. The ESB provides services with the "service" conceptual model, while allowing for optimized communication and encodings of messages. In extreme cases, the interaction between two services might bind to a local program call.
Matching of service requesters to providers can be done very early, prior to deploy time, or very late through dynamic discovery mechanisms.
SOAs require standards for the definition of services and their capabilities and interactions. The growing acceptance of XML as a standard representation of structured information and of Web services standards (often called WS-* standards) have greatly facilitated the adoption of this architectural approach. The conceptual model of SOA applies to the virtualization of both business functions and physical infrastructure. It spans the construction of applications as well as their deployment and management. Clients (users or businesses) only see a collection of business services and are interested in their quality of service, but the On Demand operating environment shields them from the details of application assembly and service delivery.
The next section explores the architecture for the On Demand operating environment and its guiding principles in more detail.
Figure 1. The On Demand operating environment architecture overview
On demand applications are business services which are built from services that provide a set of capabilities worth advertising for use by other services. Typically, a business service relies on many other services in its implementation. Services interact through the ESB, which facilitates mediated interactions between service end points. The ESB supports event-based interactions as well as message exchange for service request handling. One innovation of the ESB is a common model for messages and events. All messages can become events if deploying the service binds the message to a topic in the event space.
For both events and messages, mediations can facilitate interactions, for example, to find services providing capabilities a requestor asks for, or to take care of interface mismatches between requesters and providers that are compatible in terms of their capabilities. This article uses the term service in a very general sense, and you should note that although from the perspective of the ESB, all application components can be specified through WS-* standards (because it needs a normalized representation for efficient, mediated, capability-based matchmaking), this does not imply that they all communicate with SOAP or WS-* protocol standards -- they just need to describe themselves to the ESB in that form. The ESB supports a broad spectrum of ways to get on and off the bus, including on-ramps for legacy applications, or business connections that enable external partners in B2B interaction scenarios to participate in the service interaction game (see Note 1).
Although they all look the same from the perspective of the ESB, services implement different facets of an overall on demand application. For example, they might realize interactions with people involved in the underlying business process, provide adapters to existing applications that need to be integrated, choreograph the interaction of a number of services to achieve a business goal, watch for potential problems in the execution of the process, ready to take action to fix them should they ever occur, or manage resources required to perform the required business functions. Therefore, in addition to providing the basic infrastructure for service interactions, the On Demand operating environment identifies a set of common patterns for construction of on demand applications and provides specific capabilities to support realization of distinct service categories playing particular roles in those patterns. The two distinct service categories are integration and infrastructure service kinds.
The programming model for On Demand Business services is based on application development through component (service) assembly. On demand application builders use the services in the integration category to create new business services. The services in this category facilitate integration as well as provide business functions to be integrated. The following list explains these services.
- User access services handle adaptation from three orthogonal perspectives: 1) end point form factor such as display size, memory, and processor limitations (ranging from desktop down to pervasive devices), 2) modes of interaction including conventional display and keyboard interactions as well as speech-based interactions and combinations (multimodality), and 3) connection types such as peer-to-peer or client-to-server across a range of connection reliability including fully disconnected operations.
- User interaction services handle direct interactions with people involved in the business process, such as those who process work items spawned by choreography or collaborative process elements.
- Business process choreography services support the execution of other services that express their behavior using process flow or rule technology. Process flows, for example, are used to describe the interaction of other services (almost any of the integration kinds, including other process flow services) to perform the tasks required to realize the functions offered by the new (combined or aggregated) business service.
- Business function services provide the "atomic" business functions (those that are "not composed from other services"). These are required by the overall business service, and that includes adapters to packaged or existing custom applications as well as brand new application components created to realize a functional need not already covered by existing applications.
- Common services implement useful features, or "helper functions," designed to be used by many business services. Examples include services implementing personalization of user access and user interaction services and reporting status and progress of business services.
- Information management services help to integrate information hosted in a variety of data sources such as databases or legacy applications. These services access (query, update, and search) that information, analyze it in business intelligence scenarios, or take care of metadata about information and services used and provided by the business services living in the On Demand operating environment.
Integration services are hosted by application services that provide container facilities to simplify their participation in interactions with other integration services and with On Demand operating environment infrastructure services. On demand integration service developers focus on realizing the business logic they care about, assembling integration services that provide required business function, and declaring expected quality of service.
Programmers and administrators annotate their applications and services with policy declarations specifying quality of service. The application container (and the ESB) automates the interactions with infrastructure services to achieve the expressed policies. An application container also provides generic facilities such as taking care of security or transaction management requirements for the services it hosts, as well as "kind-specific" facilities, such as generating events reporting the status and progress of business process choreography services (see Note 2).
The services in the infrastructure category provide and manage the infrastructure into which business services and their constituents are deployed. The following list explains these services.
- Utility business services support functions like billing, metering, rating, peering, or settlement, commonly used, for example, when hosting On Demand Business services or their components.
- Service-level automation and orchestration provides services that facilitate the translation of quality of service policy declarations associated with business services into reality. This is achieved by services implementing autonomic managers which monitor the execution of services (more precisely of services instrumented to be managed elements) in the On Demand operating environment according to the policy declarations they receive. They analyze their behavior, and if the analysis indicates problems, they plan a meaningful reaction to that problem and initiate the execution of that plan. This closed feedback loop is called a MAPE (Monitor, Analyze, Plan, Execute) loop. Many specializations of such services exist, focusing on managing, such as availability, configuration, or workload for the managed elements, provisioning resources, performing problem management, handling end-to-end security for On Demand operating environment services, or managing data placement.
- Resource virtualization services provide the instrumentation of server, storage, network, and other resources (see Note 3), including structured (for example, relational) and unstructured information content held in a variety of data sources, to enable management and virtualization of those resources under the control of On Demand operating environment resource managers. Virtualization services include mapping requirements of business services and their components to available resources based on quality of service (QoS) declarations of the service and knowledge about the current utilization of available resources.
Besides the fact that they implement very different capabilities supporting a variety of On Demand operating environment patterns, the main difference between the two categories of services is which user roles build and use them. Middleware providers and ISVs build infrastructure elements, while on demand infrastructure and application builders build integration elements.
One of the most important insights of the On Demand operating environment is that a common pattern supports both application services and infrastructure services. For example:
- Adapters enable integration of existing infrastructure components into the ESB.
- Service choreography is often used for scripting of MAPE execution plans.
- The ESB provides the infrastructure for exchange of events between managed elements and autonomic managers.
- Users interact with infrastructure services through the "portal" user interaction services.
Business performance management
The three facets of the On Demand operating environment (ESB, integration services, and infrastructure services) provide the capabilities required to enable business performance management, or, management of business services to meet business goals such as key performance indicators (KPIs) identified in the analysis phase of business service implementation. Integration services are instrumented to produce business events that can be used to calculate KPIs and other metrics relevant for the management of the underlying business service. In addition, business service policies describe the expected behavior of a business service and eventually define rules for dealing with situations where those expectations are not met. Some examples of business events are business process completion, rollback, or manual intervention. A KPI might be 95% of all purchase order processes successfully completing without manual intervention.
Infrastructure services produce IT-level events reporting the status of resources business services use that can be correlated to business events produced by those services. Service-level automation services use business and IT-level events to enforce the policies associated with the business services they host. Utility business services in conjunction with the ESB collect, aggregate, and evaluate those events for presentation to business process participants in business activity workplaces.
Life cycle of an On Demand Business service
On demand application builders (see Note 4) develop business services that support particular business goals an enterprise cares about. In contrast with other services that merely realize a particular facet of an on demand application, business services "can stand on their own feet," implementing a meaningful business process or task that is offered to users (customers as well as intra-enterprise users) or other businesses the enterprise interacts with. Business services are assembled from a set of integrations services and the resulting assembly is deployed in the on demand infrastructure. On demand infrastructure managers (see Note 5) ensure that the business utility, service- level automation, and resource virtualization services required to host and manage those business service assemblies are in place.
To better understand the On Demand operating environment capabilities, service kinds, and their interactions, follow the life cycle of an on demand application from modeling of the underlying business functions and performance indicators to construction and assembly of a business service component implementing the model objectives, to the deployment of that component as a business service into the on demand infrastructure -- a day in the life of an On Demand Business service.
How to conceive business services is outside of the scope of this paper, but soon after they are conceived, a business service builder (for example, a business analyst) provides a high-level sketch of the main functions the new business service provides. They might use the Component Business Model (CBM) method (which is centered on an analysis technique that attempts to simplify the way you look at the business by identifying the unique and stand-alone set of business components) to scope the envisioned business service and position it in a model for the particular application domain.
The model identifies the main components of the envisioned application in a nearly implementation-independent way. It uses patterns similar to the ones "natively" supported by the On Demand operating environment (adapters, process choreography, business objects, and so on), thereby facilitating translation of the model into templates for implementation models defined in terms of the On Demand operating environment service kinds.
The model of the envisioned business that service analysts develop includes specification of key performance indicators the business should care about. It also includes an initial decomposition of the service into a set of activities to be performed by other services hosted in the On Demand operating environment, business entities representing information manipulated by the process, and identification of users or business partners responsible for certain aspects of the tasks to be performed to realize the desired business functions.
Figure 2. Life cycle of an On Demand Business service
Business-level modeling tools are then used to describe the interactions (processes) within the models and to simulate their execution based on estimated cost of activities, resource availabilities, and so on. The high-level models developed at this stage can then be transformed into templates for implementation-level models using patterns for business-to-IT-level mappings supported by the On Demand operating environment tools. In many cases, existing implementations of "components" or "services" are in the model, and these require rule or policy-based customization instead of implementation from a template according to the specific requirements declared in the business-level model.
Assemble new and existing components
The sketch or template an implementation-level model for a business component maps the more abstract descriptions of business tasks and entities required to achieve the goals of the new business service into a set of more specific service kinds along the lines of application patterns (e.g., adapter, mediation, choreography) supported by the On Demand operating environment.
Process choreography services orchestrate the interaction of other services along the lines of the task decomposition sketched out in the business-level model to achieve the desired business goals and externalize business rules to customize the behavior of composed services. User access services enable the execution of the task across different form factor devices, with different modes of interaction, across different connection capabilities. User interaction services enable users to contribute to the execution of those tasks and eventually interact in less formal ways using collaboration features complementing the orderly process choreography. Information management services realize the business entities identified in the business-level model, make information hosted by different kinds of data stores and back-end systems available for processing by activities in the new business service, transform and integrate information, and support business intelligence-type analysis of that information. Business function services represent existing application components (acquired packages or home-grown) that can be adapted for use in the context of the new business service through ESB adapter and mediation facilities or new components that must be built to fill in holes of functionality exposed by the new service. Common services encapsulate facilities used by many services such as tailoring interactions with people in personalized ways or supporting reporting in the context of business performance management or business intelligence.
On demand application builders also implement mediations (to be hosted by the ESB) that facilitate matchmaking in service interactions required between the constituent service components to realize the overall business service goals.
In support of business performance management, the performance indicators and other metrics defined in the business-level model are translated into instrumentation of the elements of the resulting business service component. The implementation model also specifies policy annotation for the services that make up the overall business service indicating expected quality of service for those components. The application container plays a key part in supporting the mapping of those annotations into runtime behavior, producing status change events for components they host, translating policies into interactions with the appropriate infrastructure services, and so on.
The On Demand operating environment implementation-level tools used in this phase of the life cycle of a business service support the creation of service components (new and legacy-based) as well as customization and assembly of existing components. Service creation includes development of adapters for existing applications, often providing application wrappers beyond a straightforward "service-ification" of the existing application interfaces. On Demand operating environment integration service developers can design the components they build with customization in mind. These services externalize points of variability where they delegate decisions to be made to another component. Examples include consultation of a business rule to determine the flow of execution, or QoS variants represented as policy annotations of a service. Component assembly into a new business service can be achieved in a number of ways, service choreography being a very popular variant.
More generally, the On Demand operating environment model supports the concept of a service template that uses a mix of component assembly and component customization to realize customizable, composed components that serve as templates for construction of variants of the generic business service represented by the template. Business service builders who use those templates do not need to be concerned with internals of the components they customize. The templating mechanism hides implementation details they should not worry about and only presents the points of variability of the template that can or need to be parameterized to achieve the required instantiation of the template.
Identify and design infrastructure
The resulting business service and its supporting user access and interaction, business process choreography, information management, business function, and common services will then be deployed if necessary (in some cases, already-deployed services are shared and re-used) into the On Demand operating environment infrastructure of virtualized resources. Business service builders do not need to have any knowledge of underlying (virtualized) infrastructure to perform their deployment tasks. They parameterize their service assemblies with policy annotations that are translated into requirements against the runtime infrastructure as part of the deployment process.
The On Demand operating environment supports specification and management of an overall resource model that declares available resources and their relationships. Resource requirements of an On Demand Business service are derived from policy declarations of the service and its constituents. At this stage, resource provisioning kicks in if the policy declarations of the new process require it. On demand infrastructure managers define that resource model and configure the infrastructure with the required resource managers.
Note that you can deploy the elements of a business service assembly into the On Demand operating environment infrastructure inside of an enterprise as well as off-premises. The On Demand operating environment programming model supports outsourcing of service components transparently to the business service builder who merely describes the capabilities expected from a service component used in the assembly rather than describing the particular hosting environment for that component.
And finally, a MAPE loop comprised of automation and orchestration services monitors and controls this whole ensemble. These services use the instrumentation provided for infrastructure components by middleware vendors and ISVs (partially activated to produce infrastructure-level events), as well as the instrumentation of integration-level artifacts with business-level metrics. The metrics are inspired by the performance indicators sketched out early in the business process service life cycle and translated into instrumentation of the managed element face of the integration service kinds involved here.
Note that both kinds of events (infrastructure and business-inspired) are encoded using a common event description format and therefore can be propagated through the same (common event) infrastructure (yet another application of the ESB) and correlated or aggregated independent of their source.
Note also that in addition to enabling monitoring of business and IT-level events and rendering them in KPI-oriented forms for consumption by the same people who provided the initial sketch of a business service (or maybe those who told them to do the analysis), the events captured here can automate reaction to problems encountered, or even better, detect event patterns indicating potential future problems and take action to avoid them. The actions taken are based on policy declarations related to the business services in question.
On demand infrastructure managers take care of configuring the required service-level automation and orchestration components. This is especially true for autonomic managers who understand and enforce policies declared for the elements of the business service component assemblies that are enacted.
The following sections describe the main elements of the On Demand operating environment architecture in a more systematic fashion. This is a glossary for the terms in Figure 1, with one section for each major box (arranged in alphabetical order) and information on the smaller boxes within those sections.
The application services realize containers that host integration services and business services and provide facilities to simplify their participation in interactions with other integration services and with On Demand operating environment infrastructure services.
Business is an external application system playing a role in the context of a business service interaction, through a programmatic linkage. Business might be a consumer of a service from the enterprise, or a provider of a service to the enterprise. Business can also encompass entities internal to the enterprise or external to it. For example, a geographically-dispersed, large enterprise can have multiple business units in various geographies, each of which might have its own systems and architectures with a need to do 'business' with its counterparts in other geographies.
The consumer component is business that is interested in programmatically integrating with a service that the organization under consideration provides. Consumer’s requests to external systems can be asynchronous or synchronous in nature.
The provider component is business that provides certain business functionality that the organization under consideration is interested in leveraging by establishing programmatic linkage.
A business function service implements a business function and hides the detail of its implementation. It is the functional basis for a business service and can expose its underlying function as a service, or directly as a component to be used in the choreography. The business function service can be operational or analytical in nature. The following list explains some of the business function services.
- Custom applications are business applications that have been created within an enterprise. In most cases, they are fairly old in nature and have business logic embedded within them. Though some of these applications can encompass many business processes and cross multiple functional areas within a business, most of these applications cover only a certain aspect of the business.
- Packaged applications are business applications whose source or runtime code is purchased from an external application vendor. Examples of packaged application vendors include SAP, Oracle®, and PeopleSoft®. These applications typically handle multiple functions within a business, though specialized packaged applications exist as well. Most of these applications encompass business logic and business processes.
Business performance management
Business performance management services enable business managers to create business strategies with clear and measurable goals, turn these strategies into action plans and business policies, monitor the performance of these policies to assure the KPIs are met, analyze the results of these plans to better understand performance drivers, and enable the communication of these results to various stakeholders. The overall goal of the business performance management layer is to enable a sense and respond environment, or more ambitiously, an anticipate and pre-empt environment.
In Figure 1, business performance management is positioned at the "intersection" of integration services, ESB, and integration services.
Business process choreography services
Business process choreography services support the implementation of services that express their implementation using a process flow graph to describe the interaction of other (integration) services necessary to achieve a business goal. The services encode the rules for sequencing of operations provided by those services and responsibilities of internal or external process participants for certain tasks of the underlying process. Choreography services execute the service’s specification to fully automated, or include interactive tasks that require interactions with users. The following are examples of business process choreography services:
- Choreography defines the flow of information exchanges among a set of internal or external participants -- user or business -- to implement a business process that is composed of one or more services. These services are typically Web services, but they can be generic services as well. Orchestration is typically used in the context within an enterprise, while choreography is used in the context of a virtual enterprise. IBM believes these are equivalent terms given the blurring of the boundaries of a business process.
- Business rules encode decisions that are externalized from services such as process choreography scripts. They establish the variable and conditional nature of a (process) service by describing the decisions to be made and eventually the set of actions to be taken in the case of a certain event occurring in the service, or caused externally. Rule and policy externalization is critical to the On Demand operating environment by enabling customization of existing services to meet new business requirements, instead of forcing an implementation from whole cloth for each new service and solution.
Business services are the various externalized functional service offerings which have been defined, configured, and deployed in the operating environment. A business service is the 'touch-point’ for the user or the external system, and is in reality the aggregated view of the business process that is choreographed out of functional services. Business services are identified and defined through mechanisms such as Component Business Modeling (CBM).
Common service is a functional or an infrastructural service that more than one service uses. A common service can be acquired and used as is, customized after acquisition, or built from ground up. Some examples of common services include the following:
- Acquired services are provided by an entity external to the enterprise -- typically hosted by that entity as well -- and are used by the enterprise in one or more business processes. These are the "utility" services the external entity offers to the enterprise under consideration.
- Personalization includes services that enable another service to tailor its output based on an understanding of the user profile and preferences. Personalization is not the same as customization, which is really a user-controlled action to modify the interaction to suit his or her needs, as opposed to being done by the system itself.
- Reporting covers the set of services that provide framework-type services for various applications generating reports targeted at users of all kinds. These services support both operational and analytical type reports.
An ESB provides the infrastructure that enables mediated interactions between all services. The ESB supports event-based interactions as well as message exchange for service request handling. In both cases, mediations can facilitate interactions such as finding services that provide capabilities a requestor is asking for, or taking care of mismatches between capability-wise compatible requesters and providers. The following list describes business connections and mediation, messaging, and events.
- Business connections provide intra-enterprise adapter services and B2B gateway services, enabling on demand services to interact with intra-enterprise and inter-enterprise applications both on the business and infrastructure level. Note that process coordination eventually needed for some B2B protocols (for example, RosettaNet) require additional services provided by the business process choreography layer of the architecture.
- Mediation, messaging, and events are different facets of service interaction management the ESB provides. Mediations match service requests to service providers to enable the service provider and requester to interact with each other. This includes support for dynamic matchmaking in service discovery scenarios. Service requesters and providers interact by exchanging messages in "synchronous" interactions. ESB services enable the brokering and routing of messages from a service provider to a service requester. Interactions can also be through events. In this case, "requesters" publish events not knowing (or caring) who will receive them. "Providers" register their interest in events satisfying particular filter criteria, and the ESB facilitates the matchmaking between event producers and consumers along those lines.
Information management services
Information management services provide a uniform way of representing, accessing, maintaining, managing, analyzing, and integrating data and content across heterogeneous information sources.
- Analytics services support analysis of information available in various forms and stores (examples include databases, flat files, XML files, and spreadsheets) in an enterprise. These services include both real-time analytics such as scoring, exploratory algorithms such as data mining, and decision support capabilities such as OLAP and warehouse reporting.
- Information integration services provide the ability to integrate heterogeneous data and content sources across and beyond the enterprise. In addition, they allow for data movement, transformation, and synchronization across heterogeneous-distributed databases.
- Information access services provide a uniform means for applications to access a wide variety of stored information through standard APIs such as JDBC/SQLJ and ODBC. Emerging standards for native access to XML and content are under development. Query and search are supported across relational, XML, content, and text-based sources.
- Metadata services manage both technical and business information regarding data meaning and data relationships. Business and data relationships are also often represented as hierarchies in metadata, which in turn support user navigation of the data. Data about the validity and quality of the information might also be stored, as well as frequency and currency data, schedules, and general environment management attributes. Meta-tagging supports the process of indexing, classifying, and tagging of unstructured information into a consistent taxonomy, primarily text documents and other similar objects.
Infrastructure services realize the facilities the on demand infrastructure provides. They can be categorized as utility, service-level automation, and resource virtualization services. See the individual sections for a more detailed description of those categories.
As indicated above, infrastructure services live in application containers just like integration services, but in contrast to integration services, the parameterization of those containers is not exposed in the On Demand operating environment application programming model. Also note that infrastructure services are constructed using the same principles (and tools) as business services: process choreography, adapters, business rules, and mediations -- all that is relevant when building and managing infrastructure services. This article does not discuss this in great detail since the focus is business service builders, not demand infrastructure component builders.
Resource virtualization services
Resource virtualization services enable a level of indirection between applications' usage of physical resources and the actual allocation of physical resources underneath. Examples of resource virtualization services are explained below.
- Network virtualization services enable the virtualization of the physical network, using capabilities like VPN, VLAN, and so on.
- Resource mapping services are responsible for extraction of customer legacy resource repositories and the transformation to canonical resource types for resource composition in support of business service deployment and also autonomic management interaction with on demand resources during runtime.
- Server virtualization services enable the virtualization of the physical servers across the infrastructure, using capabilities such as clustering, partitioning, and virtual machines.
- Storage virtualization services enable the virtualization of the persistent information across the distributed environment, using capabilities such as data grids.
- Information services provide the means to manage and exploit information represented by documents, e-mail, images, music, and other unstructured data. These services coordinate and enforce policies describing the life cycle and management of the information including access, security, versioning, archiving, and retention.
Service-level automation and orchestration
Service-level automation and orchestration services enable the system resources to self-configure, self-heal, self-optimize, and self-protect themselves. These functions are enabled by a set of services that are provided by autonomic managers and resource managers.
The autonomic manager receives and processes raw resource sensor input through its Monitor component. It stores the resulting data in its Knowledge base, where it can be further refined or operated upon by modules that Analyze the data to evaluate current system and resource behavior for compliance with its established policy. When system behavior is not consistent with overall goals, the autonomic manager evaluates alternative courses of action to effect changes in the set of configured resources in its sphere of influence and selects a Plan of action in accordance with policies stored in the knowledge base. The autonomic manager then invokes the Execute functions, either by interacting with underlying managed resources, or by communicating with other autonomic managers responsible for other resources in the system. This behavior pattern of autonomic behavior in an on demand system is called the MAPE loop.
Resource managers are responsible for responding to configuration change directives from higher-order autonomic service-level managers. The resource managers are in effect factories for creation and management of instances of their supported resource types. Through this component-model behavior, you can virtualize logical resource instances which are dynamically bound to underlying physical resource topologies on demand. Each logical resource is itself a service and has an identity for distributed state management and interaction. The following list describes the services associated with service-level automation and orchestration.
- Availability services let you manage the availability of the various infrastructure components within the on demand environment on a case-by-case nature, based on availability-related, service-level agreements. This might range from simple monitoring for server or software failures with automatic restart, to hot standby or failover solutions such as HACMP. Availability management also includes backup and restore (for example, ADSM), data mirroring and RAID deployment, and business continuity and disaster recovery provisioning. The overall objective and purpose of availability management is to provide a policy-declared level of resilience to the deployed solution.
- Configuration services provide the ability for the on demand environment to adapt itself to changes in the infrastructure, with minimal human intervention, based on goals and policies specified by the offering or provider administrator. This property needs to permeate the infrastructure from the highest level service down to the lowest level resource that supports that service.
- Problem management services provide appropriate logging and tracing facilities which are designed and deployed within the policy and service-level management components of the environment, to permit the debugging of the system’s behavior when SLAs are violated for no apparent reason.
- Security services provide the ability for the on demand environment to achieve self-protection. Security is managed on a case-by-case basis for the various service instances which are provisioned within the infrastructure based on SLAs, SLOs, and policies. In an on demand environment, it is not only sufficient to detect the intrusions but also important to be able to react dynamically and prevent further damage. The security architecture of each business service must also be auditable. This is for the benefit of users, the utility provider, and law enforcement. It is also necessary, for security reasons, for various events (logons, logoffs, Web hits, and so on) to be logged and retained for certain periods of time as required by law enforcement.
- Workload services provide the ability to balance performance and workload in the infrastructure when the aggregate load on all of the deployed on demand service instances exceeds the installed capacity of one or more resources provisioned in the environment. In this case, resource arbitration determines which instances will get the constrained resources and which ones will "suffer" based on the SLAs and policies that are in effect for the affected instances. Overall performance management is achieved through a combination of balancing, scheduling, and the provisioning of additional resources in order to best meet the performance-related goals across the various classes of running the system.
- Data placement services handle creation, maintenance, and destruction of caches and replicas of data. They monitor query streams in the system looking for opportunities to use caches and replicas to improve overall system performance. Placement policies that govern location and nature of caches and replicas control their decisions.
The user is a human playing a role in the context of a business service interaction using appropriate access channel devices. The user could be a user directly interacting with a business service, an employee acting as a proxy for the user, or an employee who is the user. User examples include customers, partners, suppliers, and employees.
User access services provide mechanisms to enable differing device types, modes of interaction, and connection topologies to seamlessly participate in end-to-end solutions with the On Demand operating environment. The following list explains some user access services.
- Adaptation services enable varying device capabilities based on CPU speed, RAM, persistent store, display size, operating system, processor instruction set, and so on. This includes desktops, laptops, and pervasive devices.
- Interaction services enable a spectrum of user-interaction modalities, including single modes such as visual, manual, and audible interactions. Additionally, it enables combinations of these as well as differing degrees of "richness" and styles of interaction.
- Connectivity services enable a range of topologies based on usage patterns, connection QoS Bearer network protocol, mobility, location and presence information, geographic coverage, connection billing models, domains such as single enterprise or multi-enterprise or service provider, and corresponding security models.
User interaction services provide the presentation capabilities for the user to interact with the business service. These include presentation services, collaboration services, search services, and content subscription services. The following list describes some user interaction services.
- Collaboration services enable the interaction of users with other users and are an inherent part of the human interaction. They are broadly classified into chat collaboration (such as email, chat) and team collaborations (e-meetings, team-rooms).
- Presentation services enable the formulation of business services in a form recognizable and understandable by a user, independent of user-access service used. They enable the translation of the user-entered data into information the various services can process.
The utility business services layer defines what usage of which resource or service is to be metered, defined, and allowed for rating packages to be applied. This provides supporting functions for this usage. The utility business services include the following:
- The rating/billing component provides the ability to translate technical measurements into monetary units, and then bill the subscriber appropriately. It is the process of calculating the cost or price of a resource by using its rating package (defining, for example, price per consumption) and a given metering record that measures the consumption of that resource. Additionally, penalties for SLA violations must be processed to be included in the subscriber’s bill.
- Metering services provide the ability to enable the collection of information related to the subscriber’s service and resource utilization. This utilization is expressed in terms of resource usage, or consumption. The collected information, which is produced by the metering service, is defined in a meter event. These meter events form the basis for the billing of subscribers as well as cost accounting and resource utilization reporting including the settlement of charges between different service providers for the usage of on demand services or resources.
- Peering/Settlement are both processes similar to rating and billing. Instead of billing a subscriber for the usage of the On Demand Business service, these processes perform accounting operations for resources and services the business service itself uses. Peering and settlement are both transparent to the subscriber of the business service.
This paper is the result of collaboration of a team from across IBM. Contributors included: Jim Colson, Angel Luis Diaz, Donald F Ferguson, George Galambos, Ray Harishankar, Shankar S Kalyana, Kristof Kloeckner, Jeffrey Nick, Marc-Thomas Schmidt, Sham Vaidya, and Dan Wolfson.
- Learn more about the capabilities of the On Demand operating environment with the article, "Operating environment essentials for an on demand breakthrough" (developerWorks, August 2004).
- Read about IBM and the On Demand Business.
- Check out the IBM and Banking on demand site to learn more about the IBM on demand vision for the future of banking.
- Read the whitepaper "From banks to banking: The on demand journey" (IBM Business Consulting Services).
- Find out more about IBM Patterns for e-business.
- Browse for books on these and other technical topics.
- The IBM developerWorks team hosts hundreds of technical briefings around the world which you can attend at no charge.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
