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 II Published: January 20, 2015 • Service Technology Magazine Issue LXXXVIII PDF

This is the second part of a two-part article series. The first part is published at Service Architecture – The Importance of Standardized Modeling – Part I.

Message Processing Logic

According to [REF-4], a Message Processing Logic can be defined as:

"… A fundamental part of a physical Web service architecture. It typically exists as a combination of parsers, processors, and service agents, many of which are provided by the runtime environment... Examples of message processing logic include message validation, message data transformation, and message header processing."

This relates mainly to Service as a Web-Service architectures [REF-1]. Despite that, the MPL should be taken as a fundamental block of any service architecture, not only related to web-service technology approaches so as to increase the applicability of the "Decoupled Contract" [REF-1] design pattern.

Scenarios where WS technology is not chosen for exposing the service endpoints are rare, but nevertheless there should not be a distinction about where to use an MPL component on a standard service architecture.

A clear definition will be made on where messaging/support and business/utility-driven logic within service architecture must be placed in order to promote a physically separate implementation of each one. This approach is the most effective for attaining agility on service general implementation changes, Software Configuration Management, quality-related factors, and general design and development methodology.

As per the Proposed Definition section of the Core Service Logic, the business/utility-driven logic should be finally placed within its scope, as it represents what the service needs to do in order to comply with its functional context and capabilities related functionality. In turn, the Enterprise Service Contract can't represent any kind of logic.

So to maintain CSL expected loose coupling with its related Enterprise Service Contract (as per "Decoupled Contract" [REF-1]) and overall definition autonomy, the messaging/support logic should be placed within the remaining building block, which is the Message Processing Logic.

The Messaging Processing Logic:

  • Represents the body of logic responsible of applying any kind of messaging and/or support related logic, as or not as a dependency to the effective execution of its related service capabilities, by both or either applying 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 residing inside of its service scope nor share or be placed as a dependency of the Core Service Logic implementation.
  • Must be only accessed by resources outside of its related service scope, always by the interface and endpoint defined by the Enterprise Service Contract
  • It's responsible for applying and enforcing the Policy Definitions and Validation Restrictions defined by the Enterprise Service Contract.
  • It's considered a part of a service and so it's to be governed and owned by it, and by heritage also by the governance and ownership entailed by it. Its ownership cannot be shared by actors not listed as service owners
  • Can be made by several different components, as long as these components don't affect the applicability of the last statements. Any component that does not comply with this cannot be considered part of the Messaging Processing Logic. These internal components could form dependencies between each other.

Figure 10 – MPL ownership and dependency relationships, pertaining to the proposed definition.

Applying these design principles make the MPL the only "entry point" to the physical representation of a service, as the CSL is always going to be inaccessible by anything but the MPL. Because the MPL is tightly coupled with its Enterprise Service Contract, it also supports the "Contract Centralization" [REF-1] design pattern.

It also acts as a "Service Façade" [REF-1] design pattern instance positioned between the Enterprise Service Contract and the Core Service Logic, taking charge of several common types of related expected logic [REF-1]:

  • Relaying Logic
    • "The façade logic simply relays input and output messages between the contract and the core service logic…"
  • Broker Logic
    • "The façade logic carries out transformation logic as per the patterns
    • Associated with Service Broker…"
  • Behavior Correction
    • "The façade logic is used to compensate for changes in the behavior of the core service logic…"
  • Contract-Specific Requirements
    • "…service facades are coupled to contracts in order to…support whatever interaction requirements the contracts express. This can include special security, reliability, and activity management processing requirements…"

Having all these logic types encapsulated in the MPL, the CSL can be made entirely driven by its main purpose "…assuring its service capabilities effective execution…" which allows a Software Configuration Management framework where service communication protocol, logging, and security agents or messaging data structures can be added and/or changed, heavily reducing the impact made on the concrete CSL definition, as the MPL can and will absorb all these changes, to some rational extent.

In turn, it can also absorb changes made to the CSL, so the existent consumers of the service, which are tight coupled to its Enterprise Service Contract, won't be affected by these, to some degree. This supports the "Decoupled Contract" design pattern [REF-1].

Service Component vs. Discrete Component

Now that Message Processing Logic (MPL) and Core Service Logic (CSL) building blocks have been clearly defined, the definition of two core concepts that will support the definition of its related fundamental sub-models will be engaged:

  • Service Components
  • Discrete Components

These are new definitions that allow us to differentiate the standardization of units of software (components) that can be shared between services directly through their own particular MPL and/or CSL, but reached by the scope of the service inventory architecture and governance from those which can only be shared by resources particular to each service architecture.

Service Component

The Service Component:

  • Is a unit of software made within the scope of a Service Architecture with a distinct functional purpose that regards only to the overall service functionality, and is critical to its effective operation.
  • Can only be made either within the Core Service Logic or the Messaging Processing Logic.
  • It inherits all the expected design characteristics pertaining to the parent Service Architecture building block (MPL or CSL).

Figure 11 – Service Component architectural placement, pertaining to the proposed definition.

The last two design principles are made so that a particular implemented component cannot just be related to a Service and its Architecture without taking proper measures. It must be done according to either the MPL or the CSL standards.

Another important factor that must be taken into account regarding the last two design principles is the ownership of each service component, keeping in mind the previously applied governance consideration: "Whatever is owned by a Service should be also owned by the owners of the same service."

As the MPL and CSL are owned by the service, a Service Component within any of them must also be owned by the very same service, and in turn affected by this rule.

According to this last definition, it's not possible to have an orphan component critical to a particular service, to be uncontrollably used and modified by other IT initiatives, and have non-predictable behavior (amongst other factors, such as scalability). All service-critical components must be closely related and governed by the service within which they are made.

The sub-models introduced later in this article must then pertain to either one of the fundamental models: ESC, MPL, and CSL, as defined within this article. They are mainly Service Components, given that the ESC sub-models can't be made by bodies of logic.


Figure 12 – MPL and CSL sub-models, are considered Service Components. ESC sub-models are not bodies of logic, and so they can't be defined as Service Components

Discrete Component

The Discrete Component:

  • It's a unit of software made within the scope of a service inventory, and so affected by its standardized architecture and governance system; but outside of any particular service architecture and functional scope.
  • It's owned and managed by its related Service Inventory stakeholders.
  • Does not have a purpose pertaining to any particular service, neither it can be encapsulated in a distinct functional context. It must increase the Service Inventory overall utility-logic related capabilities; it cannot apply any kind of business-driven logic, as it should be made inside of a service context.
  • Can be accessed by any Service Component and/or other Discrete Component; but cannot be accessed by resources outside of the Service Inventory.
  • Design and implementation must not rely on a service definition, nor be coupled to its contract.
  • It can be coupled to other Discrete Components, or resources residing outside the Service Inventory.
  • Does not need to define a Standardized Contract, and it could be made in any particular technology that suits its needs; as long as that technology is permitted by the Service Inventory Architecture.

Figure 13 – Discrete Component architectural placement, pertaining to the proposed definition.

This definition enables the separation and standardization of utility-related logic that could be used by many services or just operate by itself, but should not and/or could not be encapsulated by a service for several found factors, which are usually related to performance and scalability, or usability expectations outside of a service Inventory scope.

This definitely reduces the complexity of governance and management effort related to these types of solutions, promoting its registry and follow-up, standardized documentation and development, increasing re-usability potential, and decreasing the expected quantity of logic and redundancy.

Although it must be done in an autonomous fashion and outside of a Service Architecture [REF-1], it's framed within a Service Inventory Architecture [REF-1], so to reduce overall enterprise particular logic, and de-normalization.

As they cannot be accessed by resources outside of its Service Inventory, applying some precepts on the related governance system can deliver a controlled dependency and execution framework on which to control and promote its scalability, predictability, amongst other things. This is very important as Discrete Components are mainly positioned as a dependency of many existing Services, and so these factors could be partially propagated to them as well.

The Discrete Components cannot form any kind of dependency to Services residing within the same Service inventory, so to avoid any kind of indirect non-evident service-to-service coupling could ever exist by defining them.

The fact that Service Architecture [REF-1] does not apply to Discrete Components allows them to be made in a "less standardized manner." So any performance overhead entailed by Service Architecture [REF-1] could be bypassed by the definition of discrete components, and justify its appliance.

This approach is similar to the "Distributed Capability" design pattern [REF-1], on which it "allows" some particular body of logic to be made in a different technological context than what the Standardized Service Architecture dictates, so to overcome any negative impact to its related capability functional propose; the main difference is of a logical character, on which a Discrete Component does not pertain to any particular service as neither is its functional purpose, and so it's able to be freely shared between them, and to be governed in a more autonomous/agile manner.

First Conclusions

At this point, these five architectural models were defined:

  1. ESC – Enterprise Service Contract
  2. CSL – Core Service Logic
  3. MPL – Message Processing Logic
  4. SC – Service Component
  5. DC – Discrete Component

These architectural models will be used in the definitions of different specialized sub-models pertaining to each one of them, presented within the second part of this article. The important thing to keep in mind here is that nothing can be defined within the scope of the Service Inventory without pertaining to one of these fundamental models, and the soon to be defined sub-models.


Figure 14 – All the fundamental architectural models and their placement within the Service Inventory.

There could be some cases on which for particular reasons more models or sub-models, other than the ones presented in this article, would need to be defined. That's an expected approach considering each enterprise is a world of itself.

That's exactly what standardized modeling is aimed for. It allows situations such as the following to happen:

  • From a Functional Analysis stage the same Analyst could actually propose the Service Architect which candidate models to use for projecting a needed functionality on the Service Architecture, hence reducing the general gap between "Service Oriented Analysis" and "Service Logic Design" project lifecycle stages [REF-2].
  • The Service Architect could establish discussion with the Service Developers without the need of lower-lever technical details. In turn, the Service Developers would be able to talk to Service Architects with a common ground between top-tier definitions and standardization and lower-tier best practices and methodologies. This pertains to the gap between "Service Contract Design" and "Service Logic Design" and "Service Development" and "Service Testing" (up to some extent) project lifecycle stages [REF-2].
  • It enhances the development methodologies and best-practices, enabling them to be defined in alignment with each model or sub-model, increasing the development speed and effectiveness of any kind of TDD approach (by promoting modular development), easing peer-to-peer review during service development. This mainly pertains to "Service Development" and "Service Testing" project lifecycle stages [REF-2].
  • The QA and/or QC Analyst could design and apply audit/control templates based on these models, almost entirely decoupled for a particular Service Architecture instance. This is not related to a particular project lifecycle stage, but to every stage on which QA/QC processes could be applied (what is the most effective approach in most cases).
  • From the SGPO [REF-2] perspective, it could allow the definition of precepts and processes particular to each model and sub-model, in a hierarchic approach. This heavily increases the effectiveness of the overall Governance System, especially in the "Service Contract Design", "Service Logic Design", "Service Development" and "Service Testing" project lifecycle stages [REF-2].
  • It allows the definition of versioning strategies and installation/configuration processes particular to each model and sub-model, increasing the effectiveness of following Software Configuration Management and Configuration Management processes pertaining mainly to "Service Deployment and Maintenance" and "Service Versioning and Retirement" project lifecycle stages [REF-2].

References and Appendix

[REF-1] – SOA Design Patterns – Thomas Erl

[REF-2] – SOA Governance Governing Shared Services On-Premise and in the Cloud – Thomas Erl

[REF-3] – SOA Principles of Service Design – Thomas Erl

[REF-4] – -- Arcitura™ Education Inc.

[REF-5] – -- W3C

[REF-6] –," -- W3C