An Overview of SOA Concepts
Here is an introduction to some of the design principles associated with Service Oriented Solution.
Services expose their capabilities and functions through a service contract. The Standardized Service Contract emphasizes on the things to consider when you design the Services public technical interface and monitoring the quantity and nature of content that will be exposed as the service’s contract.
Emphasis is place on the aspects of contract design, including how data types and data models are defined and policies are asserted.
There is also a focus on making sure the service contracts are optimized, granular enough and standardized to guarantee that the endpoints exposed are consistent, reliable and maintainable.
Reuse is an extremely important principle in Service-Orientation. It’s so important that it becomes the core part of the typical service analysis and design processes and also forms the basis for service models.
This principle of Service Reusability emphasizes the positioning of services as an enterprise resources with agnostic functional contexts. Many design considerations are applied to make sure that individual service capabilities are designed in relation to an agnostic service context and to ensure they can promote the necessary reuse requirement.
Coupling is a connection or relationship between two entities. Coupling depends on the level of dependency between entities or components. This principles emphasizes on the creation of specific type of relationship within and outside of service boundaries, with main emphasis on reducing dependencies between Service contract, its implementation and the Service consumers.
Service Loose Coupling design principle promotes independent design and development of service log and implementation while still maintaining its interoperability with consumer that rely on the service capabilities.
There are numerous types of coupling in the design of Service, each of which can influence the content and granularity of its contract.
Service Abstraction principle emphasizes the need to hide the details of the service. Hiding the details enables and promotes loosely coupled relationships.
When considering different abstraction levels various forms of meta data comes into picture. The extent to which the Service Abstraction principle is applied can affect the granularity of the Service Contract and can also influence the cost of manageability of the service.
For services to be able to function consistently and reliably, their solution logic needs to have good control over its environment and resources.
The Service Autonomy principle supports the extent to which other design principles can be effectively realized in real world production environments by promoting design characteristics that maximizes a service’s reliability and predictability.
This principle refers to various problems that relates to the design of service logic and the service’s actual implementation environment. Isolation levels and service normalization considerations are considered to achieve optimum level of autonomy, especially for reusable services.
For services to be used as IT assets they should be easily identifiable and understood and a reusable need occurs. The service design needs to take the communications quality and its individual capabilities into account.
Excessive state information can compromise the availability of a service and reduce its scalability potential. Services should be ideally designed to be stateful only when required.
Applying the principle of Service Statelessness requires that the means of attainable statelessness be analyzed, based on the ability of the environments technology architecture to provide state management delegation.
The ability of effectively compose services is critically important to achieve the fundamental goals of service oriented computing. Services are expected to be able to participate as effective composition members, regardless of whether they need to be immediately added to the composition. The principle of Service Composability takes care of this ensuring that a variety of considerations are taken into account.
SOA: Principles of Service Design –by Thomas Erl
If an Enterprise decides to go and adopt the Service Oriented Architecture and implement the change, it has to sure analyze and understand the Benefits of SOA and if it is really essential.
Here are some of the benefits or advantages of Service Oriented Architecture.
Interoperability applies to sharing of data between the applications. The more interoperable they are, easier it is for them to exchange information. Applications that run in silo need to be integrated. Integration is a process that causes Interoperability
The goal of SOA is to have the interoperability built into the service thus eliminating the need for integration. Interoperability can be attained by decidedly applying the design principles and standards.
Federated IT Environment refers to one where applications and resources and combined and united but also their individual autonomy and self-governance is maintained. SOA strives to increase the federated aspect of the Enterprise environment. It does it by creating standardized and composable services, which creates a natural harmony across the enterprise between the applications and services.
Measuring the ROI of an enterprise solution can be difficult but it can be obvious when looked at from a long term perspective.
Traditional silo applications tend to grow over time and create complex environment which can be a very difficult to maintain and enhance.
SOA proposes creation of agnostic solution logic that can be used for multiple purposes, thus it has the benefit of re-usability. Re-usability of solution logic in services can increased ROI in long term
Agility on the organizational level refers to its ability to quickly respond to a change. SOA is very much seeking to improve organizational agility.
When SOA principles are applied across the enterprise, it results in implementation of services which are standardized and reusable and agnostic to one particular business process and application environment. As these number of services increases, and request for new change can be easily met by reusing the existing services and developing on them as required. This results in quicker project delivery and quicker adaptation to changes.
By designing a Service Oriented Architecture in alignment with but neutral to major vendor SOA platforms and by positioning service contracts as standard endpoints across the enterprise, proprietary service implementation details can be abstracted. This enables the organization to have more options to diversify their enterprises as required.
Successfully applying the Service Oriented principles and designs results in an enterprise with reduced redundancy, reduced size and operational cost and reduced overhead. This can benefit the organization through dramatic increase in efficiency and reduction in cost.
Those are some of the benefits of Service Oriented Architecture.
SOA: Principles of Service Design –by Thomas Erl
Service Oriented Architecture (SOA) has several core ideas that should be addressed in your organization’s SOA journey:
A set of services that a business wants to provide to their customers, partners, or other areas of an organization
An architectural style that requires a service provider, mediation, and service requestor with a service description
A set of architectural principles, patterns and criteria that address characteristics such as modularity, encapsulation, loose coupling, separation of concerns, reuse and composability
A programming model complete with standards, tools and technologies that supports web services, REST services or other kinds of services
A middleware solution optimized for service assembly, orchestration, monitoring, and management
What Is An Architectural Style?
An architectural style, sometimes called an architectural pattern, is a set of principles—a coarse grained pattern that provides an abstract framework for a family of systems. An architectural style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems. You can think of architecture styles and patterns as sets of principles that shape an application. Garlan and Shaw define an architectural style as:
“ߪa; family of systems in terms of a pattern of structural organization. More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined. These can include topological constraints on architectural descriptions (e.g., no cycles). Other constraints—say, having to do with execution semantics—might also be part of the style definition.”
[David Garlan and Mary Shaw, January 1994, CMU-CS-94-166, see "An Introduction to Software Architecture" at http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf]
An understanding of architectural styles provides several benefits. The most important benefit is that they provide a common language. They also provide opportunities for conversations that are technology agnostic. This facilitates a higher level of conversation that is inclusive of patterns and principles, without getting into specifics. For example, by using architecture styles, you can talk about client/server versus n-tier. Architectural styles can be organized by their key focus area. The following table lists the major areas of focus and the corresponding architectural styles.
Introduction to SOA
The SOA Elephant
SOA has become a well-known and somewhat divisive acronym. If one asks two people to define SOA one is likely to receive two very different, possibly conflicting, answers. Some describe SOA as an IT infrastructure for business enablement while others look to SOA for increasing the efficiency of IT. In many ways SOA is a bit like John Godfrey Saxe’s poem about the blind men and the elephant. Six blind men from Indostan encounter an elephant – each of the men then describes the elephant a bit differently because they are influenced by their individual experiences:
The man touching the trunk believes it to be a snake
The man touching the tusk believes it to be a spear
The man touching the ear believes it to be a fan
The man touching the elephant’s side believes it to be a wall
The man touching the tail believes it to be a rope
The man touching the legs believes they are trees.
Figure 1. Saxe’s Elephant
The blind men then engage in a series of debates about what they believe are facing them:
“…And so these men of Indostan
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong,
Though each was partly in the right,
And all were in the wrong!”
In many ways Mr. Saxe’s poem has become a prophecy for SOA. Industry analysts, pundits, bloggers and reporters engage each other in an ongoing, never-ending debate about what is or isn’t SOA. Like Mr. Saxe’s blind men, people have correctly identified many of the capabilities of SOA but largely fail to communicate the concept as a whole. The challenge of defining SOA has become so important that various vendor consortia and standards organizations have launched initiatives to try and answer the question “What is SOA?”
Get a primer on SOA, starting with the basic question of what a service-oriented architecture is and what comprises a Java-based SOA infrastructure at the core, platform, and quality-of-services level.
Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application’s business logic or individual functions are modularized and presented as services for consumer/client applications. What’s key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation. Application developers or system integrators can build applications by composing one or more services without knowing the services’ underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language.
Service-oriented architectures have the following key characteristics:
•SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services.
•SOA services communicate with messages formally defined via XML Schema (also called XSD). Communication among consumers and providers or services typically happens in heterogeneous environments, with little or no knowledge about the provider. Messages between services can be viewed as key business documents processed in an enterprise.