Mario has worked since he was nineteen, and his first job was in a Telco SOA Software Factory. Two and a half years later, he climbed to a technical leadership position in the very same factory, and took charge of its management and methodology.
One year and a half later, he attained an SOA Consultant position and has been doing SOA-related consulting projects since, regarding subjects from SOA Enterprise Maturity, Architecture & Governance System Definition, to technical leadership and general service technology technical assistance.
Mario is currently working as the SOA Practice Lead and Consultant for Globallogic, with a total of six years of experience in the field. His main business-line specialization is in the Insurance domain, but he has also worked in Telco, Retail, Healthcare, and Public Services.
He's passionate about service-orientation, vendor-neutral architecture and design standard definition, and very fond of teaching. He has been coaching and preaching on service-oriented methodology for two years now, producing a lot of related material along the way.
Mario does not have a college degree, as he has applied himself 24/7 to his work since he started. Being an electronic technician and having studied two years of Electronic Engineering, he has been training himself in what is now his specialty: service-orientation, SOA, and Service Oriented Computing.
His main career goal is to help define new industry-wide SOA Design Patterns, best practices, standards, etc., and to become a main representative of the overall service-orientation methodology.
Service Architecture – The Importance of Standardized Modeling – Part I Published: December 2, 2014 • Service Technology Magazine Issue LXXXVII PDF
In SOA Enterprise Architecture instance definitions, it's very important to clearly define design standards regarding how the fundamental building blocks of the basic Service Architecture should be designed and implemented.
These Building Blocks are [REF-1]:
Figure 1 – Service as a Component Architecture & Service as a Web Service Architecture [REF-1]
By grouping common design characteristics related to expected functional goals and several other factors, similar to what is done in the Service Layers design pattern [REF-1], standardized Models and sub-Models for each one are created. This enables policy-driven framework to be applied onto Enterprise Service Architecture definitions, as well as to any of its specific implementations (each particular Service Design).
They are named as:
Enterprise Service Contract – ESC Models
Messaging Processing Logic – MPL Models
Core Service Logic – CSL Models *
*Throughout this article, the concept of "Core Service Logic" will be used instead of the more general "Service Component" so as to reduce ambiguity.
Figure 2 – The three model categories regarding Fundamental Blocks of a Service Architecture [REF-1].
The idea is to match every definition from the Service Contact Design & Service Logic Design stages [REF-2] to a defined Model for each corresponding building block, defined in the Enterprise Service Architecture.
The importance given to this subject is based on the following premises:
The Service Contact Design & Service Logic Design [REF-2], which both entail making a particular Service Architecture instance, Service Development and Service Testing project stages, which pertain mostly to its implementation context, are the most related to the project's overall final productivity and quality.
They also produce most of its deliverables, and therefore relate to Service Governance and Audit-related processes appliance effectiveness, effort and associated costs.
In my experience as a Technical Leader of a 15-person team, for a service-oriented software factory project for a Telco company which had a very tight SLA regarding Quality and Productivity, these measures were of most importance.
The final benefits of applying this approach include but are not limited to the following:
This article will describe the rational process applied in the definition of these fundamental models and proposed sub-models, related design standards and policies, a taxonomy by which they'll be categorized, and examples made on logging and security-related cross-domain utility services.
In this section, the concepts used throughout this article will be introduced in order to establish a common informational ground. These are not intended to define anything beyond this article, but only to create a common ground between the author and readers. If these definitions are found to be useful and effective outside the scope of the article by any of its readers, please use them freely.
The reasons that initially encouraged the precise definition of these concepts will be explained below.
In my first years of service technology experience, most of which revolved around service development and technical leadership, the "Services" that were being made on each functional requirement didn't have the design characteristics or expected architecture as defined in service-orientation and SOA. The concept of "Service" was being used to name every component made on the ESB, and then primitive modelling techniques were applied to determine logical layers between them within the reference architecture.
At a first glance, by reading the "Service Layers" [REF-1] design pattern, one could think it was being applied to the project's reference architecture. It had an exposition layer (public HTTP/s endpoints), an orchestration layer (local composition components), and an adaptation layer (local legacy wrappers).
By further reading service-orientation theory, SOA design patterns, SOA Governance, and general service technology, it was clear we weren't actually doing services, but reusable integration-driven components, some local to the ESB and some public. Either way, service-orientation was not being correctly applied for its design and development.
This was a paradigmatic change in my professional identity. It couldn't be associated to an "SOA Developer" or an "SOA Technical Lead" role, but to an ESB Vendor-Specialized Integration Platform Engineer.
After this milestone, I found the need to precisely define each concept used, and apply this same criteria to architecture and governance definitions. Following this behavior, any un-effective ambiguity on the concepts and definitions used in this article will be actively avoided, so it can be read and understood by different readers in the same way intended by the author.
Enterprise Service Contract
There's not much to be clarified on this particular concept as its purpose and scope is already well defined within a Service Architecture.
The following definition is taken from serviceorientation.com [REF-4]:
"A service contract is comprised of one or more published documents (called service description documents) that express Meta information about a service. The fundamental part of a service contract consists of the service description documents that express its technical interface. These form the technical service contract which essentially establishes an API into the functionality offered by the service … A service contract can be further comprised of human-readable documents, such as a Service Level Agreement (SLA) that describes additional quality-of-service features, behaviors, and limitations."
Nevertheless, an increased definition specificity will be presented, and these "Service Description Documents" types will be organized into standardized models by grouping its related meta-information categories:
Particular SOA design patterns and best-practices will be also applied, in order to reduce preventively any difficulties related to their applicability, and increasing the Enterprise Service Contract overall alignment with service-orientation. The "Enterprise" modifier was added to the traditional definition title of "Service Contract" to make a clear distinction pertaining to the SOA fundamental design characteristic: "Enterprise Centric" [REF-1]. A more specific definition of what the "Enterprise Service Contract" concept is considered within this article will be provided in the following section.
The Enterprise Service Contract consists of two fundamental parts:
The intended separation between the Technical Contract and the Descriptive Contract has the purpose of further separating Technical details from Functional details, thus allowing distinct governance considerations to be applied.
For instance, the Descriptive Contract could be made entirely by a Business or Functional Analyst related roles, while the Technical Contract would be made by the Architectural/Technical oriented roles.
This allows a partial Enterprise Service Contract to be done on the "Service Oriented Analysis" project lifecycle stage [REF-2], before starting the following "Service Contract Design" stage [REF-2].
Figure 3 – The ESC and its two core parts, the Technical Contract and Descriptive Contract.
Having the Technical Contract and the Descriptive Contract as two separate standardized definitions allows a more effective design of the Service Registry [REF-2], allowing the alignment of the Service & Capability Profiles [REF-2] and underlying meta-data structures to each one of them, as per "Metadata Centralization" design pattern [REF-1].
It will also enhance the use of an Enterprise Repository of Service-related meta-data and documentation, on which the explicit categorization would ease its overall structure definition and governance. Each of these parts will be explained below.
Technical contract defines the technical service interface for each service capability, thus exposing them as service operations, and the associated message data structures used in each one of them.
It's further separated into two parts:
In this case, the approach is taken so the message structure of each service operation can be defined entirely separated from the technical interface used to expose it publicly. Both parts will be defined next.
Technical interface defines the fundamental technical API, communication protocol, and related physical endpoints used to expose the Service Capabilities as Service Operations, so they can be publicly accessed.
This must be done according to these design principles:
It is commonly made by Web Service Description Language (WSDL) [REF-6], and then uses the Message Structure to associate the data structures used for each service operation.
The message structure defines the data structure and is used as the request and response, if there is one, of each service operation without relying on the communication protocol used to publicly expose it, but to a standardized service messaging definition.
This standardized service messaging definition must be particular to each architecture instance, but is commonly composed of at least these three basic structures:
In turn, the Message Structure of each Technical Contract is usually made on an XML Schema (XSD) [REF-5], and commonly referred to as "Enterprise Business Messages" (EBM).
Enterprise-scoped, Agnostic, or Business-related data types should not be defined in the Message Structure, but separately as per the "Canonical Schema" [REF-1] design pattern, and then referenced.
It does not have a standardized physical or logical representation as it depends entirely on the information wanted to be related to the Enterprise Service Contract.
Further standardization effort can be made to define document templates for common descriptive information type, so to reduce ambiguity and increase Descriptive Contract normalization between services.
Must be done according to these design principles:
Core Service Logic
In many different books and made architectures, the use of "Core Service Logic," "Service Component," "Service Implementation," and other definitions express the same idea but with different non-evident connotations.
To reduce ambiguity, the concept of Core Service Logic (CSL) is used to represent the actual Service Implementation instead of "Service Component" and any other similar definitions.
But "Service Implementation" should not be so easily named. In my experience, several definitions of this concept were found, and while all of them true in some way, each remained insufficient to explain it to its full extent:
These definitions go beyond the scope of what is explained on serviceorientation.com [REF-4]:
"When a Web service is custom-developed, its underlying components are referred to as core service logic…The design of core service logic is affected by the application of service-orientation…Core service logic is also known as business logic..."
Next, the implications of using each one of these commonly found definitions will be exemplified in theoretical implementations of SOA Architecture and Governance. After that, a proposed definition of what the CSL is considered to be within this article will be described.
Definition A - The body of logic that does what the service capabilities require
There are three main scenarios regarding this definition:
In , the scenario fits very well with the definition, but it is not a common case.
Figure 4 – CSL not accessing any remote capabilities.
In , the scenario makes the remote capabilities part of the CSL, as they are needed for the service capabilities to function. If they are a part of the service, they should be affected by the related SOA instance and SOA Governance system, which in almost all situations fails to be true.
Figure 5 – CSL encapsulating remote capabilities as part of its definition
Only in  making a CSL in its service architecture can be avoided, in which case the Messaging Processing Logic (MPL) would be responsible of accessing the remote capabilities directly; but although the CSL won't do anything, it could serve as a facade between the Messaging Processing Logic (MPL) and the remote capabilities being accessed, which is why this last approach its usually never used.
Figure 6 – MPL accessing the remote capabilities directly, without passing through a CSL.
Definition B - The logic which is made just for that service
This is the most difficult definition to take into consideration by itself, as it doesn't take into account certain situations, such as the following:
"We could just encapsulate an existing body of logic and build a Service Architecture on top of it."
Figure 7 – A remote resource accessing existent implementation made part of the CSL definition.
This is a common case where an enterprise already has some kind of non-standardized services, such as web services or simple components, commonly made by easy-to-use frameworks which in turn don't usually take the "Contract First" approach preached by the "Standardized Service Contract" [REF-3] principle, and in cases where project time and resource constraints force architects to use existent implementations. This subject is further explained in the "Problem" and "Impacts" sections of the "Contract Centralization" design pattern [REF-1].
In this case, the logic was not actually made for one particular service, and it could still be accessed by other services or by non-service consumers even before being encapsulated, thereby reducing the overall applicability of the "Service Autonomy" [REF-3] design principle.
Definition C - The logic which is "owned" by the service
This is the most effective definition at first sight, because of its relation to service architecture and effective governance definitions. In order to better understand the last statement, the following governance consideration must be taken into account:
This entails something very important:
If there are defined precepts and processes that support this approach, one could never affect a service behavior without proper authorization and change management.
Although this is an ideal situation, the fact that the CSL could depend on remote capabilities that exist outside of the service inventory makes the scope and effectiveness of this approach difficult to define and/or achieve.
The following related disputes are commonly found:
Figure 8 – CSL sharing ownership between its related Service, and remote owners.
The Core Service Logic:
Figure 9 – CSL ownership and dependency Relationships, pertaining to the proposed definition.
This definition, together with the upcoming proposed definition for the Messaging Processing Logic, makes the CSL a very autonomous component. It only needs to support its related service capabilities' effective execution and functional goals, but it's not directly coupled with the Enterprise Service Contract and its technical interface definition as the MPL is strategically positioned between them to support just that.
This means the CSL can be developed on any technology, as long as it does what it is supposed to. The MPL would take charge of allowing the functionality made on the CSL to finally be mapped to each service capability and its related endpoint, and vice-versa, as defined in its Enterprise Service Contract. This would allow the CSL to evolve without affecting existing consumers.
These two last statements support the effective application of "Decoupled Contract" design pattern [REF-1], in which case the MPL will take the role of the "Contract Medium" and support the "Service Loose Coupling" design principle [REF-3].
By not allowing the CSL to form dependencies with resources residing outside the Service Inventory, its autonomy and predictability is further increased. Any restriction or negative implications entailed by this policy will be treated by the "Resource Adapter" (Discrete Component sub-model).
[REF-1] SOA Design Patterns, Thomas Erl
[REF-2] SOA Governance Governing Shared Services On-Premise and in the Cloud, Thomas Erl et. al
[REF-3] SOA Principles of Service Design, Thomas Erl
This article will continue in Part II.