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 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 serviceorientation.com [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:
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]:
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:
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.
The Service Component:
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
The Discrete Component:
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.
At this point, these five architectural models were defined:
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:
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] – http://serviceorientation.com/ -- Arcitura™ Education Inc.
[REF-5] – http://www.w3.org/XML/Schema -- W3C