It's regrettable that the foundational principles of SOA were overshadowed by the specific technologies and vendors of that era, leading to a perception of SOA primarily through that lens. Just as photocopying isn't synonymous with Xeroxing, it's important to distinguish the core principles of SOA from the technologies it was initially associated with.
A significant portion of my discussion regarding Service-Oriented Architecture (SOA) draws from the definition outlined in the Open Group’s Source Book. This source stands out because it refrains from defining SOA solely within the technological context prevalent during its early commercial adoption in the early 2000s.
SOA has nothing to do with Enterprise Service Bus (ESB) or Messaging Standards such as JMS.
SOA has nothing to do with protocols and specifications like SOAP or WSDL or even concrete implementations like web services for that matter.
It's crucial to disengage from associating architectural approaches solely with specific implementation technologies. SOA fundamentally represents an architectural style, independent of the tools or protocols utilized.
Here is Source Book definition:
“A service:
Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)
Is self-contained
May be composed of other services
Is a “black box” to consumers of the service“ “
In my forthcoming post, I aim to connect this definition with the concept of "microservices" - exploring their essence and rationale. However, even the Open Group's definition on this subject appears somewhat perplexing. Yet, before delving into microservices, let's establish a foundation by clarifying what exactly SOA entails. To do so effectively, it's imperative to grasp its origins and evolution.
Pre SOA Era
The narrative of SOA begins during the Dot-Com Era, spanning the period both before and after its burst.
The internet was still in its adolescence, and e-commerce was just beginning to gain widespread attention.
The business landscape was largely dominated by enterprises constructing their business functions in isolated silos. This approach led to the generation of data that struggled to move efficiently through bureaucratic red tape and organizational bottlenecks.
During that period, both business leaders and technology vendors acknowledged that these bottlenecks in information flow were impeding business growth and stifling technology driven transformation and innovations.
The isolated enterprise functions often independently procured, and managed systems that were discrete and mirrored the business silos of that era.
These systems were costly to integrate (often in some form of point to point communication) and generated and managed the data within the organizational boundaries.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F09807ce0-1418-4e6f-9fc4-2d6092660687_1881x1030.png)
SOA Mainstream Era
The web had evolved beyond flashy websites catering to niche interests like ordering pizza for nerds. E-commerce had transformed into a way of life, fueled by innovative enterprises that emerged from the ashes of the Dotcom bust.
During this era, technology vendors recognized the demand for more robust frameworks to facilitate enterprise application development. This led to the creation of J2EE by Sun Microsystems and .Net by Microsoft, both aiming to address the evolving needs of businesses in building scalable and efficient software solutions.
Numerous data exchange formats and protocols, including XML and SOAP, gained widespread adoption following the introduction of native support in J2EE and .Net frameworks.
During this period, the concept of federated security and service access control began to mature alongside advancements in public key infrastructure (PKI) and transport-level security standards like SSL/TLS. These developments laid the groundwork for more secure and interoperable systems, ensuring robust protection for sensitive data and streamlined access to services across networks.
Enterprise frameworks, such as J2EE and .Net for enterprise software development were now mainstream. They borrowed the business concept of “Service“ and provided means to implement them in software constructs.
Enterprise services didn't initially emerge as web services, but HTTP over TCP became a de facto standard for network communications, leading to the emergence and maturation of the concept of "Web Services." Specifications for the endpoints managing such requests began to surface, exemplified by the Java Servlet Specification.
Enterprise technologists became increasingly comfortable implementing the concept of "service," which held the promise of offering a versatile and agile interface for integrating systems in a loosely coupled manner.
The "implementation style" of this architectural concept was constrained by the enterprise systems of that era, predominantly designed as functional monoliths with limited interface capabilities. As a result, the prevalent choice to make the services talk to each other was to adopt another architecture style, "Message Driven Design," often realized through a Message Broker, colloquially referred to as an Enterprise Service Bus.
Now such implementations looked like this
Critical Observations
The key observation from Figure 2.0 is that the services added in front of the monolithic enterprise applications were essentially functional monoliths themselves. This underscores the importance of understanding what constitutes a monolith.
These functional monolithic services were just as bulky as their monolithic enterprise software counterparts.
This wasn't a flaw in the architectural concept of SOA. Rather, it was influenced by various factors, such as technologies of that era, but primarily because the rationale and methods for decomposing or independently scaling services within enterprises of that era were often constrained or influenced by the limitations of their business architecture.
Concept(Microservice) != Concept(RESTful);
Concept(SOA) != Concept({SOAP,WSDL,ESB})
Utilizing a message broker (or an ESB) to facilitate communication between two or more collaborating services is NOT considered a "microservice antipattern." In fact, it's a common practice, particularly in implementing and integrating micro-batches in modern systems. These message brokers, in their different forms, enable various communication paradigms such as push or pull, and they also support the implementation of the generalized architectural pattern known as "pipes and filters."
Era of Planet Scale Computing and Public Clouds
The scaling challenges in the traditional business enterprises of the previous era were limited by the footprint of their businesses.
Scaling challenges instead became more apparent in the new wave of startups and enterprises embracing Web 2.0 concepts, offering services on a planetary scale.
These enterprises weren't hampered by legacy business architectures. In fact, their business architecture was shaped by the products they developed and delivered on the World Wide Web.
As a result, their approach to defining services extended beyond initial definitions, striving to anticipate load factors and scalability constraints early in the design process.
For instance, a function like document upload, which in the past might have been constrained by the size of a traditional enterprise's customer base, is now limited by a value several times larger—reflecting the global population with internet access.
The scale necessitated decomposing services according to scalability constraints and independently scaling them across various tiers and layers.
This necessity marked the emergence of more granular services, characterized by a greater degree of separation of concerns. Industry parlance dubbed them microservices. While they are "micro" in their scope, they still embody the essence of services, and their design strategy remains aligned with SOA principles. There's no denying it.
Stay tuned for further discussion on this topic, including a deeper exploration of the design strategy inherent in SOA, which underpins microservices architecture.