Mario Mesaglio

Mario Mesaglio


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.


rss  subscribe to this author


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]:

  • Service Contract
  • Message Processing Logic (mostly used in web-service related architectures)
  • Service Component (core service logic)

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:

  • A technology-neutral communication framework on which to enable fluid collaboration between different domain roles and development teams.
  • A technology-neutral procedural framework that increases the effectiveness of standardized QA and Custodian-related processes.
  • A technology-neutral methodological framework that enables the definition of technology-specific best-practices and other measures.
  • A technology-neutral governance framework that enables the definition of Software Configuration Management, Configuration Management, and Versioning related policies and methodologies.
  • Increased normalization of particular Service Architecture Instances, reducing overall ambiguity and design-related effort, enabling standardized QC processes and reducing the general quantity and variety of related documentation & subsequent development.
  • Increased development speed and overall quality, enabling the definition of a finite common set of technology-specialized templates related to each model, and reducing ad hoc implementation instances.

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.

Identity Crisis

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 [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:

  • Technical Interface
  • Message Data Structures
  • Behavioral Extensions
  • Service Policies & SLA

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.

Proposed Definition

The Enterprise Service Contract consists of two fundamental parts:

  • Technical Contract
  • Descriptive Contract.

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

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:

  • Technical Interface
  • Message Structure.

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

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:

  • Must define the fundamental technical API needed to access the capabilities of a particular service by exposing endpoints as per "Canonical Protocol", "Canonical Schema" and "Schema Centralization" design patterns [REF-1], and with an optional appliance of "Dual Protocols" [REF-1] design pattern.
  • Must define the technical API for all service capabilities, but does not have to use a same endpoint for every one of them as long as each capability pertains to at least one of them, as per "Canonical Protocol" [REF-1] design pattern.
  • Must be done completely decoupled of any technical details of a particular Service's underlying technical implementation, as per "Decoupled Contract" [REF-1] design pattern.

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.

Message Structure

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:

  • Request - Service Operation Request Message.
  • Response - Service Operation Response Message. Optional.
  • Fault - Service Operation Fault Response Message. Optional.

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.

Descriptive Contract

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:

  • Must define all the non-technical behavior-related information about the capabilities of a particular service, so as to establish their complete execution context scope.
  • Must define all SLA-related policies of the Service Behavior, regarding no less than these three main SLA categories: QoS, Business and Security; if these policies could be also technically enforced on an industry-standardized manner in the Technical Contract (WS-* for example), they must then also be done in that way, reducing any kind of negative redundancy with its definition on the Descriptive Contract.

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:

  • The body of logic that does what the service capabilities requires?
  • The logic which is made just for that service?
  • The logic which is "owned" by the service?

These definitions go beyond the scope of what is explained on [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:

  1. The CSL applies 100% of the logic needed for each of its related service capabilities.
  2. The same as [1], but it also needs to access capabilities found outside its related service architecture, to some extent.
  3. The CSL applies a minimum quantity of logic, and it relies almost entirely on the capabilities found outside of its related service.

In [1], the scenario fits very well with the definition, but it is not a common case.


Figure 4 – CSL not accessing any remote capabilities.

In [2], 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 [3] 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:

  • Whatever is owned by a Service should be also owned by the owners of the same service.

This entails something very important:

  • Every change made on the CSL should then be notified, discussed, and approved by its service owners.

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:

  • Who owns these remote capabilities that are critical to the service functionality?
  • What happens if these remote capabilities need to change?
  • Could their owners be asked to share thoughts before applying this change?
  • Should then a Shared Governance framework be applied?
  • Could that be seen as ineffective bureaucracy by main stakeholders?

Figure 8 – CSL sharing ownership between its related Service, and remote owners.

Proposed Definition

The Core Service Logic:

  • It is the body of logic responsible for assuring its service capabilities' effective execution, by both or either applying business/utility-related particular logic within its definition and/or recurring to capabilities outside of the service scope, but only from the same service inventory (local capabilities).
  • Must not be accessed by any component or resource outside of its service scope, including resources inside (local resources) or outside (remote resources) the service inventory, nor share or be placed as a dependency of any of its underlying logic and/or dependencies.
  • Must only be accessed by the Messaging Processing Logic.
  • It is considered a part of a service, so is therefore governed and owned by it and by heritage, as well as by the governance and ownership entailed by it. Its ownership cannot be shared by actors who are not listed as service owners.
  • It can be made up of several different components, as long as these components don't affect the applicability of the last statements. Any component that does not comply with the previous requirements cannot be considered part of the Core Service Logic. These internal components could form dependencies on each other.

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.