Welcome!

Thomas Erl

Subscribe to Thomas Erl: eMailAlertsEmail Alerts
Get Thomas Erl via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, SOA Best Practices Digest, SOA & WOA Magazine, Microservices Journal

Book Excerpt

Book Excerpt: Service-Oriented Computing Fundamentals

Service-oriented computing is an umbrella term that represents a new generation distributed computing platform

This excerpt describes fundamental terms and concepts associated with service-oriented computing, including those related to service-oriented architecture, service-orientation, and cloud computing.

Service-Oriented Computing
Service-oriented computing
is an umbrella term that represents a new generation distributed computing platform. As such, it encompasses many things, including its own design paradigm and design principles, design pattern catalogs, pattern languages, a distinct architectural model, and related concepts, technologies, and frameworks.

Service-orientation (explained shortly) emerged as a formal method in support of achieving the following goals and benefits associated with service-oriented computing:

  • Increased Intrinsic Interoperability - Services within a given boundary are designed to be naturally compatible so that they can be effectively assembled and reconfigured in response to changing business requirements.
  • Increased Federation - Services establish a uniform contract layer that hides underlying disparity, allowing them to be individually governed and evolved.
  • Increased Vendor Diversification Options - A service-oriented environment is based on a vendor-neutral architectural model, allowing the organization to evolve the architecture in tandem with the business without being limited only to proprietary vendor platform characteristics.
  • Increased Business and Technology Domain Alignment - Some services are designed with a business-centric functional context, allowing them to mirror and evolve with the business of the organization.
  • Increased ROI - Most services are delivered and viewed as IT assets that are expected to provide repeated value that surpasses the cost of delivery and ownership.
  • Increased Organizational Agility - New and changing business requirements can be fulfilled more rapidly by establishing an environment in which solutions can be assembled or augmented with reduced effort by leveraging the reusability and native interoperability of existing services.
  • Reduced IT Burden - The enterprise as a whole is streamlined as a result of the previously described goals and benefits, allowing IT itself to better support the organization by providing more value with less cost and less overall burden.

Figure 1: The latter three goals listed in the previous bulleted list represent target strategic benefits that are achieved when attaining the first four goals.

Note that these strategic goals are also commonly associated with SOA.

Service-Orientation
Service-orientation
is a design paradigm intended for the creation of solution logic units that are individually shaped so that they can be collectively and repeatedly utilized in support of the realization of the specific strategic goals and benefits associated with service-oriented computing.

Solution logic designed in accordance with service-orientation can be qualified with "service-oriented," and units of service-oriented solution logic are referred to as "services." As a design paradigm for distributed computing, service-orientation can be compared to object-orientation (or object-oriented design). Service-orientation, in fact, has many roots in object-orientation and has also been influenced by other industry developments.

Figure 2: Service-orientation is very much an evolutionary design paradigm that owes much of its existence to established design practices and technology platforms.

The service-orientation design paradigm is primarily comprised of eight specific design principles:

  • Standardized Service Contract - "Services within the same service inventory are in compliance with the same contract design standards."
  • Service Loose Coupling - "Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment."
  • Service Abstraction - "Service contracts only contain essential information and information about services is limited to what is published in service contracts."
  • Service Reusability - "Services contain and express agnostic logic and can be positioned as reusable enterprise resources."
  • Service Autonomy - "Services exercise a high level of control over their underlying runtime execution environment."
  • Service Statelessness - "Services minimize resource consumption by deferring the management of state information when necessary."
  • Service Discoverability - "Services are supplemented with communicative metadata by which they can be effectively discovered and interpreted."
  • Service Composability - "Services are effective composition participants, regardless of the size and complexity of the composition."

Figure 3: The principles on the left have a regulatory influence, whereas the application of the principles on the right primarily results in concrete characteristics being established within the service architecture.

Service-Oriented Architecture (SOA)
Service-oriented architecture
is a technology architectural model for service-oriented solutions with distinct characteristics in support of realizing service-orientation and the strategic goals associated with service-oriented computing.

The four base characteristics we look to establish in any form of SOA are:

  • Business-Driven - The technology architecture is aligned with the current business architecture. This context is then constantly maintained so that the technology architecture evolves in tandem with the business over time.
  • Vendor-Neutral - The architectural model is not based solely on a proprietary vendor platform, allowing different vendor technologies to be combined or replaced over time in order to maximize business requirements fulfillment on an on-going basis.
  • Enterprise-Centric - The scope of the architecture represents a meaningful segment of the enterprise, allowing for the reuse and composition of services and enabling service-oriented solutions to span traditional application silos.
  • Composition-Centric - The architecture inherently supports the mechanics of repeated service aggregation, allowing it to accommodate constant change via the agile assembly of service compositions.

These characteristics collectively define the fundamental requirements a technology architecture must fulfill to be fully supportive of service-orientation.

As a form of technology architecture, an SOA implementation can consist of a combination of technologies, products, APIs, supporting infrastructure extensions, and various other parts. The actual complexion of a deployed service-oriented architecture is unique within each enterprise; however, it is typified by the introduction of new technologies and platforms that specifically support the creation, execution, and evolution of service-oriented solutions. As a result, building a technology architecture around the service-oriented architectural model establishes an environment suitable for solution logic that has been designed in compliance with service-orientation design principles.

Services

Figure 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, along with the four SOA characteristics, are explained in detail in the book SOA Design Patterns.)

NOTE
Let's briefly recap the previous three terms to clearly establish how they relate to each other and specifically how they lead to a definition of SOA:

  • There is a set of strategic goals associated with service-oriented computing.
  • These goals represent a specific target state.
  • Service-orientation is the paradigm that provides a proven method for achieving this target state.
  • When we apply service-orientation to the design of software, we build units of logic called "services."
  • Service-oriented solutions are comprised of one or more services.
  • To build successful service-oriented solutions, we need a distributed technology architecture with specific characteristics.
  • These characteristics distinguish the technology architecture as being service-oriented. This is SOA.

Figure 5: The chorded circle symbol is used to represent a service, primarily from a contract perspective.

A service is a unit of logic to which service-orientation has been applied to a meaningful extent. It is the application of service-orientation design principles that distinguishes a unit of logic as a service compared to units of logic that may exist solely as objects, components, Web services, REST services, and/or cloud-based services.

Subsequent to conceptual service modeling, design, and development stages implement a service as a physically independent software program with specific design characteristics that support the attainment of the strategic goals associated with service-oriented computing.

Each service is assigned its own distinct functional context and is comprised of a set of capabilities related to this context. Therefore, a service can be considered a container of capabilities associated with a common purpose (or functional context).

It is important to view and position SOA and service-orientation as being neutral to any one technology platform. By doing so, you have the freedom to continually pursue the strategic goals associated with service-oriented computing by leveraging on-going service technology advancements.

Any implementation technology that can be used to create a distributed system may be suitable for the application of service-orientation. Three common service implementation mediums currently exist: components, Web services, and REST services. Any of these forms of service implementations can also exist as cloud-based services (as explained in the upcoming Cloud section).

Services as Components
A component is a software program designed to be part of a distributed system. It provides a technical interface comparable to a traditional application programming interface (API) through which it exposes public capabilities as methods, thereby allowing it to be explicitly invoked by other programs.

Components have typically relied on platform-specific development and runtime technologies. For example, components can be built using Java or .NET tools and are then deployed in a runtime environment capable of supporting the corresponding component communications technology requirements, as implemented by the chosen development platform.

Figure 6: The symbols used to represent a component. The symbol on the left is a generic component that may or may not have been designed as a service, whereas the symbol on the right is labeled to indicate that it has been designed as a service.

Services as Web Services
A Web service is a body of solution logic that provides a physically decoupled technical contract consisting of a WSDL definition, one or more XML Schema definitions and also possible WS-Policy expressions. The Web service contract exposes public capabilities as operations, establishing a technical interface but without any ties to a proprietary communications framework.

Service-orientation can be applied to the design of Web services. Web services provide an architectural model whereby the service contract is physically decoupled and vendor-neutral. This is conducive to several of the design goals associated with service-orientation.

Figure 7: Three variations of a single Web service showing the different physical parts of its architecture that come into play, depending on the role it assumes at runtime.

Services as REST Services
REST services
(or RESTful services) are designed in compliance with the REST architectural style. A REST service architecture focuses on the resource as the key element of abstraction, with an emphasis on simplicity, scalability, and usability. REST services can be further shaped by the application of service-orientation principles.

Figure 8: A REST service, depicted similar to a Web service, except for the service contract symbol that indicates the service is accessed via a uniform contract.

More Stories By Thomas Erl

Thomas Erl is a best-selling IT author and founder of Arcitura Education Inc., a global provider of vendor-neutral educational services and certification that encompasses the Cloud Certified Professional (CCP) and SOA Certified Professional (SOACP) programs from CloudSchool.com™ and SOASchool.com® respectively. Thomas has been the world's top-selling service technology author for nearly a decade and is the series editor of the Prentice Hall Service Technology Series from Thomas Erl, as well as the editor of the Service Technology Magazine. With over 175,000 copies in print world-wide, his eight published books have become international bestsellers and have been formally endorsed by senior members of many major IT organizations and academic institutions. To learn more, visit: www.thomaserl.com

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.