"entirely belongs to" shareholding

Chapter 1 Introduction to Services

3.1. Service Terminology Service

a service is a software program that makes its functionality available via a technical interface, called a service contract.

Figure 3.1. The symbol used to represent an abstract service.

Service Contract

The symbol used to represent a service contract is displayed in Figure 3.2.

Service Capability

A service contract can be broken down into a set of service capabilities, each of which expresses a function offered by the service to other software programs.

Figure 3.4. A Purchase Order service contract with four service capabilities.

Service Consumer

A service consumer is software program when it accesses and invokes a service—or, when it sends a message to a service capability

Service Agent

A service agent is an event-driven program that does not provide a published technical interface.

Service Composition

A service composition is an aggregate of services collectively composed to automate a common task.

Figure 3.6. A generic symbol used to represent a service composition.

REST Services and SOA

REST provides architectural and technology-specific design requirements, service- orientation (and SOA) provides a technology-neutral approach to service design that can be applied to a number of service

Figure 3.8. Service-orientation is comprised of a set of design principles that are collectively applied to shape software programs into service-oriented units of logic. Chapters 4 and 7 and Appendix D provide more information about these principles.

Chapter 2. SOA Terminology and Concepts

Chapter 2. SOA Terminology and Concepts

Service-oriented computing is an umbrella term that represents a distinct distributed computing platform. Service-orientation emerged as a formal method in support of achieving the following goals and benefits (Figure 4.1) associated with service-oriented computing:

• Increased Intrinsic Interoperability • Increased Federation • Increased Vendor Diversification Options • Increased Business and Technology Alignment • Increased ROI • Increased Organizational Agility • Reduced IT Burden

Figure 4.4. The layered SOA model establishes the four common SOA types: service architecture, service composition architecture, service inventory architecture, and service-oriented enterprise architecture. (These different architectural types are explained in detail in the book SOA Design Patterns.)

Service Models

A service model is a classification used to indicate that a service belongs to one of several predefined types based on the nature of the logic it encapsulates, the reuse potential of this logic, and how the service may relate to domains within its enterprise.

The following three service models are common to most enterprise environments and therefore common to most SOA projects: • Task Service • Entity Service • Utility Service

Service Inventory

A service inventory is collection of complementary services within a boundary

Service-Related Granularity

• Service Granularity – This represents the functional scope of a service.

• Capability Granularity – The functional scope of individual service capabilities is represented by this level. For example, a GetDetail capability

• Constraint Granularity – The level of validation logic detail

• Data Granularity – This granularity level represents the quantity of data processed. For example, a fine level of data granularity is equivalent to a small amount of data.

Figure 4.7. The four granularity levels that represent various characteristics of a service and its contract. Note that these granularity types are, for the most part, independent of each other.

Service Profiles The document used to record details about a service throughout itslifecycle is the service profile(Figure 4.8). A service profile is typicallymaintained by the owner or custodian of a service and is based on atemplate that is standardized throughout a service inventory.