Expertise

Research

SOA

Loose coupling, the basic philosophy behind Service Oriented Architecture represents the next major architectural step in distributed computing.    SOA provides a way to  control, manage, deploy and track loosely-coupled services scattered throughout the enterprise.  See inside why an SOA might be on your enterprise horizon.

Services-oriented architecture (SOA) is a significant advance in improving the flexibility and reuse of business logic. However, SOAs don't address the challenge of ensuring that business data is delivered in a consistent and semantically correct manner. In fact, they exacerbate the problem of maintaining consistent definitions for business entities such as customer, product or invoice.

Because SOAs emphasize loosely coupled interactions between services, they must move data from one service to another with enough context, quality and syntactic structure to allow services to perform their tasks independently of any other. Each service must ensure that inbound and outbound data is not only syntactically correct, but also is valid and complete in the context of the business process being performed.

Service Oriented Architecture is the large scale structuring of Business Processes, Applications and Distributed Systems around reusable, loosely coupled, transport independent message oriented Units of Capability called “Services.”  Services themselves are independent, composable, discoverable packets of capability that are externally defined only by endpoints, expected communication message contents and logical functionality. 

The Principles of SOA Compliance and Loose Coupling

SOA is a type of enterprise architecture. However, the difference between SOA and other approaches to enterprise integration is in the business agility that SOA offers. Business agility is the ability of a company to respond quickly and efficiently to change and to leverage change for competitive advantage. For the architect, designs that provide business agility imply creating an IT infrastructure that meets as-yet-unknown business requirements -- a situation that throws traditional IT planning and design out the window. 

To meet the needs of the agile enterprise, the practice of SOA has the following core principles:

The business drives the services and the services drive the technology

In essence, services act as a layer of abstraction between the business and the technology. The service-oriented architect must understand the dynamic relationships between the needs of the business and the available services as well as the technical underpinnings that offer the layer of abstraction required by the services. 

Business agility is a fundamental business requirement

Instead of dealing with concrete requirements from business, SOA considers the next level of abstraction: The ability to respond to changing requirements is the new ''meta-requirement.'' The entire architecture -- from the hardware on up -- must reflect the business agility requirement, because any bottleneck in the SOA can torpedo the flexibility of the entire IT environment. 

A successful SOA is always in flux

To visualize how a SOA is supposed to work, it is better to think of a living organism rather than the traditional ''building a house'' metaphor that gave software architecture its name. IT environments are in a constant state of change, so the work of a service-oriented architect is never done. For the architect used to building houses, tending to a living organism requires a new way of thinking.  

The foundations of SOA
There are two popular movements in IT - one architectural and the other methodological - and each has something to offer the service-oriented architect. First is the Model-Driven Architecture (MDA), which is championed by the OMG, the same standards body that looks after CORBA. MDA states that architects should begin with a formal model of the system being built in the Unified Modeling Language (UML), which is also shepherded by the OMG. MDA begins with a platform-independent model that represents the functional requirements and use cases of the users of the system. From this platform-independent model, architects can derive whatever platform-dependent models they need to specify the design of the system under construction. These platform-dependent models are so detailed that they can be used to automatically generate the implementation code itself. 

The core strength of MDA is that the designs for systems are fully specified; thus, there is little leeway for misinterpretation when the systems are built and the models can be used to generate working code. But MDA has some limitations. First, MDA assumes that the business requirements are fully specified before the model is built, which is not the case in the typical dynamic business environment. Second, MDA does not offer a feedback loop. If developers need to diverge from the models, there is no set way to keep the models up to date. The second foundation of SOA is the Agile Methodology (AM) approach, most notably represented by concepts available in the XP framework.  AMs like XP provide a process for building software systems in environments where requirements are in flux and occasionally unknown. XP requires that a user representative work closely with the development team, helping to write tests that guide the daily work of the developers. All members of the team contribute to the design, which is kept as minimal and informal as possible. The goal of AM is to build just what the user wants, avoiding extraneous work on artifacts like formal models. AM's core strength lies in its agility -- the ability to deal with changing requirements. AM's weakness is its limited scalability. For example, XP works well for small teams and projects of moderate size, but as the project scope grows, it becomes more difficult for team members to have a solid grasp of all aspects of the project without a concrete, comprehensive plan to work from. 

On the surface, MDA and AM appear to be contradictory -- MDA assumes fixed requirements, while AM assumes the opposite. MDA centers on formal models, while AM eschews them. However, at the risk of being iconoclastic, we will take certain elements from each of these approaches and put them together into a coherent architectural approach.  

Complying with the first principle of SOA - the business drives the services and the services drive the technology - AM connects the business model directly to the implementation, as represented in the platform-dependent model. MDA does not separate the business model from the platform-independent model, but takes the platform-independent model as its starting point. SOA must connect these models (levels of abstraction) into a single architectural approach. We will make this connection by looking at the five-view approach to architecture. 

The five-view approach to SOA
Enterprise architects find their profession both challenging and gratifying because they must consider IT from many perspectives. These perspectives are distilled into what we call the five-view approach when applied to SOA.

The four lower views represent different ways of looking at the architecture, representing specific stakeholders. The logical view represents the users' functional requirements. Business analysts work with the process view, which addresses the runtime issues of the software. The implementation view describes the organization of the software code and is the view used by the developers. The deployment view maps software to the underlying platforms and associated hardware, the way that systems specialists view the architecture. The fifth view, the use-case view, overlaps the other views and plays a special role with regard to the architecture. In the case of SOA, the service-oriented architect must be able to connect the users to the services, and the services to the underlying technology, following the threads of use cases in the use-case view. 

To show how the service-oriented architect must work with each of these views, let’s put them in the context of the SOA meta-model. There are two overlapping realms of SOA: The business realm represented by the business model/service model and the technology realm represented by the service model and the platform-dependent model (the service model is shared by the two realms). Business users who use the logical and process views work with coarse-grained business services, orchestrating them into processes that depend on the fluctuating requirements of the business. Technologists, on the other hand, work to build and maintain the abstraction layer between the services and the underlying technology. The central model, representing the services themselves acts as the axis around which the business moves. 

The SOA meta-model inherits the platform-independent and platform-dependent models from MDA, but adds AM's interaction with the user as well as an agile feedback loop, represented by the two-way arrows between the components. Likewise, the meta-model solves AM's scalability issue by introducing the intermediate level of abstraction provided by the central service model. Users can thus deal with the day-to-day concerns of the business, reflecting any changing requirements in the service model. Technologists can then respond to these changing requirements quickly and effectively because the underlying technology is model-driven. 

What is different about the practice of SOA and more traditional approaches to enterprise architecture is the way it enables agility. Remember that the third principle of SOA states that SOAs are always in flux. This environment of constant change is the cornerstone of the practice of SOA. The line between design time and runtime blurs as the technologists respond to the changing business requirements that are a normal part of day-to-day operations. 

The Missing Piece

The ultimate measurement of a standards compliant SOA is the concept of loose coupling. 

Genuine loose coupling enables tightly aligned business integration and is defined as the ability of individual nodes in a distributed system to change without affecting or requiring change in any other part of the architecture.   

The primary reason for introducing loose coupling is to essentially manage change in a system. It is not a feature that is necessary for a system to operate; rather it’s a way to manage the complexity introduced by change. The advancements in computer languages are really to build abstraction to manage complexity and one kind of complexity is change. 

The concept is simple; define a dimension and then identify how to decouple the different end points of a dimension. There are four dimensions where we can introduce some kind of decoupling: 

There are three different mechanisms available to enable decoupling:  

Decomposition Mechanism

The ability to break up a procedure call into 2 components, the action and the continuation.  

Schema is defined as the complete definition of syntax for a language. Those that require a context free grammar versus systems that require only partial definition.   

Communication from one party to another consists of a sentence with a verb and a noun. First of all there needs to be an agreement on semantics.  However, we can standardize on the semantics for the verb part and therefore allow certain classes of communications to be possible without prior agreement between the parties.  This may seem to be pushing the problem down to another level; however there are certain classes of communication that do not require full knowledge of the complete sentence.

Intermediary mechanism

Instead of 2 events occurring at the same time, allow them to occur at different times and have the original semantics preserved. This is achieved ideally through brokered interaction services[1] or less desirably, point-to-point services[2].

Typing Mechanism

Static/dynamic typing and strong/weak typing are two totally different concepts, and unfortunately very often confused by a lot of people. Proponents of weakly typed languages often label strong typing superfluous.  

The argument is the same as that used against interfaces and abstract classes. It's unnecessary language fluff when all you need is common sense programming techniques. Anyway, here's two primary benefits derived from strong typing:

Explicit statements of intent
If you believe that programming is done for "humans first, machines second" then it follows that strategies promoting explicit statements of intent are more efficient.

Strong typing is a communication tool for explicit statements of intent backed by the guard of compilation. Method signatures with strong typing tell you exactly what kind of input they expect and what kind of output they return. The compiler doesn't allow you to break those rules. Weak typing, on the other hand, requires you to be verbose about input and output requirements in comments and vigilant about checking parameters manually. 

Error prevention by failing at compile time
Having the compilation guard insures that methods aren't exposed to types that fail to meet signature requirements. It's about failing fast. In weakly typed languages, you won't be alerted to programming errors, such as passing a method a string when it expected an array, before a problem arises at runtime. That's late and expensive. 

The table below defines dimensions and mechanisms. It is important to understand that end points are not only entities communicating with applications but also entities that make that communication intelligent. The ultimate measure of loose coupling is dynamic services which are defined as independent, composable, discoverable packets of capability that are externally defined only by endpoints, expected communication message contents and logical functionality.