Service granularity principle

Last updated

In the context of software engineering and software architecture, service granularity is a key design concern when applying the paradigm of service-orientation for instance during service-oriented modeling. Service granularity specifies the scope of business functionality and the structure of the message payload in a service operation that is provided within a service-oriented architecture (SOA).

Contents

Definition

Service granularity is both an application domain concern (business granularity), as well as a software interface design issue (technical granularity); it is a property of the service contract exposed by a service provider. It pertains to the semantics and syntax of the in (request) and out (response) message content, which can be viewed as instances of two general Enterprise Integration Patterns, Command Message and Document Message. By definition a coarse-grained service operation has broader scope than a fine-grained service, although the terms are relative. The former typically requires increased design complexity but can reduce the number of calls required to complete a task. [1]

Criteria

Due to the fallacies of distributed computing, finding an adequate granularity is hard. [2] There is no single simple answer but a number of criteria exist (see below). A primary goal of service modeling and granularity design is to achieve loose coupling and modularity, which are two of the essential SOA principles, [3] and to address other architecturally significant requirements.

Many forces influence the service granularity; [4] four particularly relevant factors to consider when designing for an adequate granularity are performance, message size, transactionality and business function:

Business function

Ideally, each service operation maps to a single business function, although if a single operation can provide multiple functions without adding design complexity or increasing message sizes, this generality can reduce implementation and usage costs.

Performance

Web services are accessed remotely and calls to web service operation create more network overhead. Reducing the number of service requests reduces that overhead.

Message size

Coarse-grained services may pass more data than fine-grained services, including data that is not specifically required for the task. This complicates message processing in the endpoint and might in turn harm performance. Reducing message size may require adding a more fine-grained operation.

Quality-of-service characteristics including transactionality

For conceptual clarity each service operation should perform a single system-level transaction and leave data integrity across service boundaries to the business logic in the service consumer. This also simplifies error recovery, and typically eases design.

Many more decision criteria for finding an appropriate granularity exist; there is no global optimum. Sixteen such coupling criteria are compiled from the literature in. [5]

Patterns

As one size does not fit all, the design of service granularities can benefit from many existing pattern works on various kinds of distributed systems, especially those related to services, as well as pattern works related to API design (e.g., API design in object-oriented programming) and enterprise integration. An overview of such languages is given here.

Related Research Articles

In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.

Granularity, the condition of existing in granules or grains, refers to the extent to which a material or system is composed of distinguishable pieces. It can either refer to the extent to which a larger entity is subdivided, or the extent to which groups of smaller indistinguishable entities have joined together to become larger distinguishable entities.

Enterprise application integration (EAI) is the use of software and computer systems' architectural principles to integrate a set of enterprise computer applications.

Representational state transfer (REST) is a software architectural style that describes the architecture of the Web. It was derived from the following constraints:

<span class="mw-page-title-main">Enterprise service bus</span> Communication system in a service-oriented architecture

An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA). It represents a software architecture for distributed computing, and is a special variant of the more general client-server model, wherein any application may behave as server or client. ESB promotes agility and flexibility with regard to high-level protocol communication between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex service landscapes.

In computing and systems design, a loosely coupled system is one

  1. in which components are weakly associated with each other, and thus changes in one component least affect existence or performance of another component.
  2. in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling.

A mashup, in web development, is a web page or web application that uses content from more than one source to create a single new service displayed in a single graphical interface. For example, a user could combine the addresses and photographs of their library branches with a Google map to create a map mashup. The term implies easy, fast integration, frequently using open application programming interfaces and data sources to produce enriched results that were not necessarily the original reason for producing the raw source data. The term mashup originally comes from creating something by combining elements from two or more sources.

Event-driven architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events.

Service-orientation is a design paradigm for computer software in the form of services. The principles of service-oriented design stress the separation of concerns in the software. Applying service-orientation results in units of software partitioned into discrete, autonomous, and network-accessible units, each designed to solve an individual concern. These units qualify as services.

IBM App Connect Enterprise is IBM's premier integration software offering, allowing business information to flow between disparate applications across multiple hardware and software platforms. Rules can be applied to the data flowing through user-authored integrations to route and transform the information. The product can be used as an Enterprise Service Bus supplying a communication channel between applications and services in a service-oriented architecture.

Service-oriented architectures (SOA) are based on the notion of software services, which are high-level software components that include web services. Implementation of an SOA requires tools as well as run-time infrastructure software. This is collectively referred to as a service-oriented architecture implementation framework or (SOAIF). The SOAIF envisions a comprehensive framework that provides all the technology that an enterprise might need to build and run an SOA. An SOAIF includes both design-time and run-time capabilities as well as all the software functionality an enterprise needs to build and operate an SOA, including service-oriented:

Service-oriented architecture library (SOALIB) is used to distribute reusable service-oriented architecture (SOA) software in a manner similar to other computing libraries. SOA consists of loosely coupled interoperable services which use messaging based on both Simple Object Access Protocol (SOAP) and Representational State Transfer (REST). A library in computing is a set of compiled modules which are tested and ready for reuse. A similar concept is used for SOA, in that whatever technology is used to develop the service can also be distributed in library form. A Java-based SOA library may be distributed in Web ARchive (WAR) or Enterprise Archive (EAR) file formats. C, C++, and .NET applications may be distributed as a shared object, a Dynamic Link Library, or as an executable file.

Event-driven SOA is a form of service-oriented architecture (SOA), combining the intelligence and proactiveness of event-driven architecture with the organizational capabilities found in service offerings. Before event-driven SOA, the typical SOA platform orchestrated services centrally, through pre-defined business processes, assuming that what should have already been triggered is defined in a business process. This older approach does not account for events that occur across, or outside of, specific business processes. Thus complex events, in which a pattern of activities—both non-scheduled and scheduled—should trigger a set of services is not accounted for in traditional SOA 1.0 architecture.

Service-orientation design principles are proposed principles for developing the solution logic of services within service-oriented architectures (SOA).

The standardized service contract is a software design principle applied within the service-orientation design paradigm to guarantee that service contracts within a service inventory adhere to the same set of design standards. This facilitates standardized service contracts across the service inventory.

In computing, service composability is a design principle, applied within the service-orientation design paradigm, that encourages the design of services that can be reused in multiple solutions that are themselves made up of composed services. The ability to recompose the service is ideally independent of the size and complexity of the service composition.

Service layer is an architectural pattern, applied within the service-orientation design paradigm, which aims to organize the services, within a service inventory, into a set of logical layers. Services that are categorized into a particular layer share functionality. This helps to reduce the conceptual overhead related to managing the service inventory, as the services belonging to the same layer address a smaller set of activities.

In software engineering, Canonical Schema is a design pattern, applied within the service-orientation design paradigm, which aims to reduce the need for performing data model transformation when services exchange messages that reference the same data model.

A microservice architecture – a variant of the service-oriented architecture structural style – is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols. One of its goals is that teams can develop and deploy their services independently of others. This is achieved by the reduction of several dependencies in the code base, allowing for developers to evolve their services with limited restrictions from users, and for additional complexity to be hidden from users. As a consequence, organizations are able to develop software with fast growth and size, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. Interfaces need to be designed carefully and treated as a public API. One technique that is used is having multiple interfaces on the same service, or multiple versions of the same service, so as to not disrupt existing users of the code.

In parallel computing, granularity of a task is a measure of the amount of work which is performed by that task.

References

  1. ↑ Josuttis, N. (2007). SOA in Practice. Sebastopol, CA, USA: O'Reilly. ISBN   978-0-596-52955-0.
  2. ↑ F. Leymann Loose Coupling and Architectural Implications, ESOCC 2016 keynote
  3. ↑ Krafzig, D., Banke, K., Slama, D. (2004). Enterprise SOA: Service-Oriented Architecture Best Practices 1st Edition. Prentics Hall. ISBN   978-0131465756.
  4. ↑ Page 21 in Zimmermann, O., Guidance Models and Decision-Making Tooling for SOA, Cloud, and Outsourcing Solution Design, http://resources.sei.cmu.edu/asset_files/Presentation/2011_017_001_24654.pdf
  5. ↑ Service Cutter: A Systematic Approach to Service Decomposition, M Gysel, L Kölbener, et al.. European Conference on Service-Oriented and Cloud Computing, 185-200, (PDF)
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.