SOA Best Practice - Fundamental Design Terminology and Concepts

Fundamental Design Terminology and Concepts - SOA Service Oriented Architecture Best Practice

Note: This definition was copied from www.SOAGlossary.com.

SOA Service Oriented Architecture Best Practice : A best practice is generally considered a technique or approach to solving or preventing certain problems. It is usually a practice that has industry recognition and has emerged from past industry experience.

Figure: Best practices provide guidance in the form of general “lessons learned.” In the example, it is suggested that the on-going maintenance of reusable solution logic units from all applications fall under a single custodian.

How then is a best practice differentiated from a design principle? In this book we make a clear distinction in that a design principle is limited to design only. A best practice can relate to anything from project delivery to organizational issues, governance, or process. A design principle could be considered a best practice associated only with solution design.

SOA Design Standard - Fundamental Design Terminology and Concepts

Fundamental Design Terminology and Concepts - SOA Service Oriented Architecture Design Standard

Note: This definition was copied from www.SOAGlossary.com.

SOA Service Oriented Architecture Design Standard : For an organization to successfully apply a design paradigm, it will require more than an adherence to the associated design principles and a knowledge of supporting design patterns. Every organization will have unique strategic goals and unique enterprise environments. These form a distinct set of requirements and constraints that need to be accommodated within solution designs.

Design standards are (usually mandatory) design conventions customized to consistently pre-determine solution design characteristics in support of organizational goals and optimized for specific enterprise environments. It is through the use of internal design standards that organizations can consistently deliver solutions tailored to their environments, resources, goals, and priorities.

As with design principles, the application of design standards results in the creation of specific design characteristics. As with design patterns, design standards foster and refine these characteristics to avoid potential problems and strengthen the overall solution design. In fact, it is recommended for design standards to be based upon or even derived from industry design principles and patterns.

Figure: In this case, a design standard requires that C’s original design be altered to remove access to a shared, external state database.

Can you have design standards without design principles? Yes, it is actually common to have many design standards. Only some may need to relate back to principles in order to see through the application of the overall design paradigm. Different design standards may also be created to simply support other goals or compensate for constraints imposed by specific environmental, cultural, or technology-related factors. Although some standards may have no direct association with accepted design principles, there should always be an effort to keep all standards in relative alignment.

Can you have design principles without design standards? It usually depends on how committed an organization is to the governing design paradigm. If it sees potential in only using a subset of the paradigm’s principles, then some principles may not be supported by corresponding design standards. However, this approach is not common. Essentially, as with design principles, through standardization we want to build consistency into specific design characteristics – consistency in the quality of the characteristics and in how frequently they are implemented.

Note that one point of clarification worth making when discussing standards is the difference between design standards and industry standards. The former, as we just described, refers to internal or custom standards that apply to the design of solution logic and systems for a particular enterprise. The latter generally represents open technology standards, such as those that comprise the XML and Web services platforms.

Sometimes organizations assume that if they use industry standards they will end up with a standardized IT enterprise. While those XML and Web services specifications that have become ratified and accepted industry standards do establish a level of technology standardization, it is still up to an organization to consistently position and apply these technologies. Without design standards, industry standards can easily fail in achieving their potential.

SOA Design Pattern Language - Fundamental Design Terminology and Concepts

Fundamental Design Terminology and Concepts - SOA Service Oriented Architecture Design Pattern Language

SOA Service Oriented Architecture Design Pattern Language : The application of one design pattern can raise new issues or problems for which another pattern may be required. A collection of related patterns can establish a formalized expression of a design process whereby each addresses a primary decision point. Combining patterns in this manner forms the basis of a pattern language.

A pattern language is essentially comprised of a chain of related design patterns that establish a configurable sequence in which the patterns can be applied. It provides a highly effective means of communicating fundamental aspects of a given design approach because it supplies detailed documentation of each major step in a design process that shapes the design characteristics of solution logic.

Figure: A sequence of related design patterns formalize the primary decision points of a design paradigm. In this example, the logic in application design B is decomposed as a result of one pattern, and then further decomposed as a result of another. Subsequent fundamental patterns continue to shape the logic.

SOA Design Pattern - Fundamental Design Terminology and Concepts

Fundamental Design Terminology and Concepts - SOA Service Oriented Architecture Design Pattern

Note: This definition was copied from www.SOAGlossary.com.

SOA Service Oriented Architecture Design Pattern : We've established that service-orientation is a design paradigm comprised of a set of design principles, each of which provides a generalized rule or guideline for realizing certain design characteristics. The paradigm itself sounds pretty complete, and it actually is. However, to successfully apply it in the real world requires more than just a theoretical understanding of its principles.

Service designers will be regularly faced with obstacles and challenges when attempting to apply a design paradigm in the real world. This is because the realization of desired design characteristics is frequently complicated by various factors, including: - Constraints imposed by the technology being used to build and/or host the units of solution logic.

• Constraints imposed by technology or systems that reside alongside the deployed units of solution logic.
• Constraints imposed by the requirements and priorities of the project delivering the units of solution logic.

A design pattern describes a common problem and provides a corresponding solution. It essentially documents the solution in a generic template format so that it can be repeatedly applied. Knowledge of design patterns not only arms you with an understanding of the potential problems designs may be subjected to, it provides answers as to how these problems are best dealt with.

Figure: Patterns provide recommended solutions for common design problems. In this simplified example, a pattern suggests we reduce external access to a database to increase application autonomy.

Design patterns are born out of experience. Pioneers in any field had to undergo cycles of trial and error and by learning from what didn’t work, approaches that finally did achieve their goals were developed. When a problem and its corresponding solution were identified as sufficiently common, the basis of a design pattern was formed. Design patterns can be further combined into compound patterns that solve larger problems and a series of patterns can form the basis of a pattern language, as explained next.

SOA Design Paradigm - Fundamental Design Terminology and Concepts

Fundamental Design Terminology and Concepts - SOA Service Oriented Architecture Design Paradigm

SOA Design Paradigm : There are many meanings associated with the term “paradigm.” It can be an approach to something, a school of thought regarding something, or a combined set of rules that are applied within a predefined boundary.

A design paradigm within the context of business automation is generally considered a governing approach to designing solution logic. It normally consists of a set of complementary rules or principles that collectively define the overarching approach represented by the paradigm.

Figure: Because a design paradigm represents a collection of design principles, it further increases the degree of commonality across different bodies of solution logic. In the example, the amount of reuse in A and B has increased.

Object-orientation (or object-oriented design) is a classic example of an accepted design paradigm. It provides a set of principles that shape componentized solution logic in certain ways so as to fulfill a specific set of goals.

Along those very same lines, service-orientation represents its own distinct design paradigm. Like object-orientation, it is a paradigm that applies to distributed solution logic. However, its principles differ from those associated with object-orientation, which results in the creation of different types of design characteristics.

Note that the service-orientation design paradigm is documented separately at www.soaprinciples.com.

SOA Design Principle - Fundamental Design Terminology and Concepts

Fundamental Design Terminology and Concepts - SOA Service Oriented Architecture Design Principle

Note: This definition was copied from www.SOAGlossary.com.

SOA Design Principle : A principle is a generalized, accepted industry practice. In other words, it’s something others are doing or promoting in association with a common objective. You can compare a principle with a best practice, in that both propose a means of accomplishing something based on past experience or industry-wide acceptance.

When it comes to building solutions, a design principle represents a highly recommended guideline for shaping solution logic in a certain way and with certain goals in mind. These goals are usually associated with establishing one or more specific design characteristics (as a result of applying the principle).

Figure: The repeated application of design principles increases the amount of common design characteristics. In this case, the coupling between solution logic units A and B has been loosened (as indicated by a reduction of connection points).

For example, we can have a principle as fundamental as one that states that solution logic should be distributable. Applying this principle results in the solution logic being partitioned into individually distributable units. This then establishes the distinct design characteristic of the solution logic becoming componentized. This is not only an example of a very broad design principle, it is also the starting point for service-orientation.

The eight design principles documented in SOA: Principles of Service Design provide rules and guidelines that help determine exactly how solution logic should be decomposed and shaped into distributable units. A study of these principles further reveals what design characteristics these units should have to be classified as "quality" services capable of fulfilling the vision and goals associated with SOA and service-oriented computing.

SOA Design Characteristic - Fundamental Design Terminology and Concepts

Fundamental Design Terminology and Concepts - SOA Service Oriented Architecture Design Characteristic

Note: This definition was copied from www.SOAGlossary.com.

SOA Design Characteristic : A characteristic of something is simply an attribute or quality. An automated business solution will have numerous unique characteristics that were established during its initial design. Hence, the type of design characteristic we are interested in is a specific attribute or quality of a body of solution logic that we document in a design specification and plan to realize in development.

Figure: In this simple example, three distinct application designs (A, B, C) are established, each with its own distinct list of design characteristics. We will continue to reference these applications in the upcoming pages. (Note that the small squares represent units of solution logic, solid arrows represent reuse or shared access, and dashed arrows represent state data transfer.)

Service-orientation emphasizes the creation of very specific design characteristics, while also de-emphasizing others. It is important to note that almost every design characteristic we explore is attainable to a certain measure. This means that it is generally not about whether solution logic does or does not have a certain characteristic; it is almost always about the extent to which a characteristic can or should be realized.

Although each system can have its own unique characteristics, we are primarily interested in establishing common design characteristics. Increased commonality ensures an increased degree of consistency, making different kinds of solution logic more alike. When things are more alike they become more predictable. In the world of distributed, shareable logic, predictability is a good thing. Predictable design characteristics lead to predictable behavior. This, in turn, leads to increased reliability and the opportunity to leverage solution logic in many different ways.

Much of service-orientation is dedicated to providing a means of establishing a specific collection of design characteristics that spread consistency, predictability, and reliability on many levels and for different purposes.

Source: www.whatissoa.com

SOA Introduction - Fundamental Design Terminology and Concepts

Fundamental Design Terminology and Concepts - SOA Service Oriented Architecture Introduction

SOA Introduction : Before we can begin exploring the details of service-oriented computing, we first need to establish some basic design terminology. The books in this series use a common vocabulary comprised of the following design-related terms:

- Design Characteristic
- Design Principle
- Design Paradigm
- Design Pattern
- Design Pattern Language
- Design Standard
- Best Practice

Depending on your sources, you will find differing definitions for these terms. More often than not, though, you will notice that they all are somewhat intertwined. The upcoming pages explain each term and the following figure illustrates how they inter-relate.

Figure: Fundamental design terms establish a basic taxonomy used throughout the upcoming chapters. This diagram hints at how some parts of a basic design framework can relate to each other.

Source: http://www.whatissoa.com/

Service Oriented Architecture (SOA) - Concepts, Components, and Standards

Service Oriented Architecture (SOA) - Concepts, Components, and Standards BY DR. PETER EICHHORST

The Necessity of an Architecture Framework

The first section of this series discussed the problems of today’s IT landscape. The sectioned described how the tight coupling between IT applications was responsible for inflexible IT processes and inefficient application integration. With Service Oriented Computing (SOC), the applications are assembled as Services that communicate with one another using accepted communication standards. Services are autonomous and implement only the business logic but do not concern themselves with process flow or data transformation logic. In order for the loosely couple services to communication with one another, and architectural framework is required. A Service Oriented Architecture SOA is an infrastructure framework that enables autonomous, loosely coupled services (with defined interfaces) to communicate with one another without point-to-point calls between any of the services. It enables internal and external system integrations and the reuse of application logic by enabling the composition and orchestration of services. SOA Service Oriented Architecture offers a complete paradigm change away from the object-oriented client/server paradigm in which very fine grained objects communicate with one another. On the basis of a Service Oriented Architecture SOA, loosely coupled services communicate with one another only indirectly, on a high level and through standardized documents. SOA Service Oriented Architecture facilitates the flexible design of business processes and the agile IT implementation of these processes and “composite” services.

Components of an SOA Service Oriented Architecture

In order for loosely coupled services to communicate with one another (by exchanging standardized documents) and in order to execute the services in the appropriate flow, an Service Oriented Architecture SOA consists of two base components: The Enterprise Service Bus (ESB) is responsible for the message distribution and the Service Orchestration Engine (SOE) is concerned with the flow of the business process. Both components work in together in tandem to accomplish the communication between loosely coupled services in a defined process flow.

Web Services (WS) communicate with one another (as shown in the diagram above) in a loosely coupled manner with each WS not “knowing” to which other WS it sends messages or from which WE it receives messages from. To accomplish this, the ESB utilizes an Publish/Subscribe principle in which service clients never directly call the service providers – they don’t even “know” that the providers exist! Generally, the service client sends a message document with all of the data it deems as “relevant” (so that the Service Provider can do its business function) to the ESB. The Service Client registered with the ESB as a Document Publisher and provided the ESB with its document schemas. In order for a service provider to receive documents from a client (via the ESB), it must register with the ESB and subscribe to all of the client documents (schemas) that it is intended to receive. This means that the service provider requests from the ESB to send it all documents published by the clients to which the provider subscribes. Due to existing document standards (XML and schema standards), the service provider can programmatically parse this document and exe-cute its business functions using the extracted data. The Service Provider (publisher) also registered its output schema with the ESB and the Service Client registered as a Subscriber to this same document (in order to receive the response from the provider). The service publisher produces a resulting XML document (with a published schema) and sends it to the ESB, which then sends the document to all services that subscribe to the document. The publish/subscribe principle enables services to communicate with one another in an indirect manner through an ESB. Therefore, the services are loosely coupled because the service client does not “know” which service it is calling and the service provider does not “know” which service it is being called by and to whom the service results are being sent to. But, the services are still not totally loosely coupled because the service publisher must “know” the document schema of the service client and vice versa! This problem is solved by a SOA infrastructure in the following manner: Services register as clients or publishers and provide their document schemas. For every schema published to the ESB, there is a standard schema (also called a Canonical Schema) defined in the ESB. The ESB contains an XML Document Translator that translates all published documents into the appropriate canonical document. The is accomplished using a translation document (XSLT in the XML standard) that contains data translation information. Using this mechanism, a service publishes its output document to the ESB which translates it to a canonical document (using an XSLT document). The ESB then uses additional translators to translate the canonical document to the input documents of all services that subscribe to the document. Up to this point in the article, it is still unknown how the flow of the service communication is accomplished. Using only an ESB, when several services subscribe to the same schema, all of the subscribers will now always receive the document (which is not the desired outcome).

In the example Order Process introduced in the first section of this series, both the “Approval” and “Order” services subscribe to the “Purchase Request” document.

In the ESB scenario described above, both of the subscribing services would always receive the Purchase Request document each time it is published. This is why the ESB must work together with a Service Orchestration component that informs the ESB when to send the appropriate documents based upon business conditions. The diagram below illustrates how the flexible Order Process is implemented within a Service Oriented Architecture SOA Environment in which the ESB and Service Orchestration Engine (SOE) work in tandem:

The SOE receives a canonical document from the ESB which contains specific variables (x and y) that are used to determine the flow of the process. The SOE determines which services are to be call next based on the evaluation of the business rules in the process model. Once the appropriate services are determined but the SOE, it sends a message to the ESB informing it which services are to be called next. In the example “Order Process” the SOE informs the ESB to call the “Order” service if the variable x <= 1000 or it informs the ESB to call the “Approval “ service if the variable x > 1000. Although both of the services subscribe to the same schema (document), only one of the services actually receives the document upon completion of the Purchase Request service. The diagram also illustrates how the document flow and document translation works. It is important to remember that the Service Orchestration Engine never communicates directly with the physical web services, rather through logical service endpoints that receive the canonical documents. In order to quickly develop easily changeable applications and processes on the basis of a Service Oriented Architecture, a SOA development environment is required consisting of many tools that the concepts described above can be achieved without heavy coding, but instead with simple configurations! This includes a tool that makes it possible to create process models that can be interpreted by the SOE as well as a tool to create business rules used within the processes. The example “Order Process” contains two business rules that must be defined: Rule 1 – Approval Required: when x>1000 and Rule 2 – Approved: when y=ok.

Service-Oriented Architecture (SOA): Concepts, Technology, and Design

Service-Oriented Architecture (SOA): Concepts, Technology, and Design by Thomas Erl

Book Description

This is a comprehensive tutorial that teaches fundamental and advanced SOA service oriented architecture design principles, supplemented with detailed case studies and technologies used to implement SOAs in the real world.

***We'll have cover endorsements from Tom Glover, who leads IBM's Web Services Standards initiatives; Dave Keogh, Program Manager for Visual Studio Enterprise Tools at Microsoft, and Sameer Tyagi, Senior Staff Engineer, Sun Microsystems. All major software manufacturers and vendors are promoting support for SOA Service Oriented Architecture. As a result, every major development platform now officially supports the creation of service-oriented solutions.

Parts I, II, and III cover basic and advanced Service Oriented Architecture SOA concepts and theory that prepare you for Parts IV and V, which provide a series of step-by-step "how to" instructions for building an Service Oriented Architecture SOA. Part V further contains coverage of WS-* technologies and SOA platform support provided by J2EE and .NET.

Barriers to a successful SOA service oriented architecture project

Barriers to a successful SOA service oriented architecture project

If you're getting the idea that using service oriented architecture SOA principles will require more time and effort initially, you're right. While the basic concepts of service oriented architecture SOA are fairly simple to understand, actually doing the work required to architect a solution that uses service-oriented principles will require more effort than using traditional point-to-point methods to architect a solution.

We've already discussed some of the benefits of service oriented architecture SOA. While the promise and perhaps the hype will motivate many to undertake service oriented architecture SOA projects, several barriers can stand in the way of their success. This failure to achieve optimal results doesn't have to be your experience. Before you dive in to your own service oriented architecture SOA plans, consider how your organization will handle the following barriers:

Reluctance to collaborate across teams and organizations. Interdepartmental politics is one of the largest barriers to realizing a successful service oriented architecture SOA project. Such politics can keep teams from working together to define an architecture of services that may cross departmental boundaries. These services may in fact need to cross development team boundaries. Services also may require lines of business and IT to work together more closely than they may have before. To make projects succeed, development teams must be rewarded not only for how well they implemented their own part of the architecture, but also for how well those pieces participate in the greater architecture.

Unwillingness to learn a different approach and/or lack of background understanding. Many of us tend to cling to the known and resist shifting to the unknown. On the other hand, many architects and developers may be willing to learn but lack the basic education required to understand the service oriented architecture SOA approach. Architecting solutions using service-oriented principles will require both the willingness to learn some additional skills and the basic background needed to help acquire those skills. This means that if your organization is new to SOA, you should account for the need for education as part of your service oriented architecture SOA adoption plans. And plan for this education both in terms of the cost needed to ramp up, and the time needed to ramp up. Because service oriented architecture SOA is relatively new, formal educational opportunities will be few. As a result, many teams today are finding it most effective to learn through direct experience.

Focusing on technologies rather than architecture. It's tempting to immediately start looking at Web services and imagine how you'd start mapping existing functionality to service interfaces. Slow down—while some in the SOA field believe that it's effective to approach service oriented architecture SOA in a bottom-up manner, doing so can run the risk of creating services that are only of limited use in other projects. Jumping immediately to focusing on technologies also runs the risk of creating services that are less loosely coupled than may be desired.

Unwillingness or inability to make necessary investments. The nature of the business and the need to deliver solutions on a tight time schedule often makes it difficult to use service oriented architecture SOA, especially if you're starting from scratch. As we've addressed, you should expect to make a substantial initial investment in time and possibly in platforms and frameworks in order to realize benefits on your successive efforts. The worst situation occurs when business or IT teams launch an service oriented architecture SOA initiative without fully counting the cost. Acknowledging these costs and planning for them up front can increase your business' chances of launching a successful SOA initiative.

Taking on too large of a project. Avoid taking on more than you can handle at once. For instance, trying to convert an entire organization's application functionality over to an service oriented architecture SOA at once can be problematic. It is important to make sure you determine the appropriate services to enable based on potential cost savings, reusability and revenue. In other words, start small. Then build out your services in an incremental fashion. This will give you time to learn, succeed, and realize increasing returns on leveraging services you've already created.

Characteristics of a service - SOA Service Oriented Architecture

Characteristics of a service - SOA Service Oriented Architecture

Another way to understand Service Oriented Architecture SOA is by looking at it from the perspective of the characteristics of its services. Consider these factors as you evaluate whether the services you define adhere to Service Oriented Architecture SOA principles:

Services should be meaningful. Ideally, you'll design services to meet business requirements as well as functional requirements. These services should be at an appropriate level of granularity tailored to their location in the architecture. (We'll discuss granularity in more detail in a later section.)

Services should be contract-based. The service itself is implemented with the clear understanding that it is fulfilling a set of obligations that are expressed in a contract that is shared between the service provider and the service consumer. As a result, service's consumer can better understand what it must provide to that service and what that service will provide in return. This is more than a definition of operations on a service, but it also should include the semantics of how the service is used. The contract should include specific policies that define who may access the services, what service levels might be expected, etc.

Services should be self-contained and modular. Services should be able to stand on their own with few dependencies. Where dependencies exist to other application functionality or other services, access should be as loosely coupled as possible. In addition, much like you would define an object in object-oriented analysis, services should be cohesive. They should have a single cohesive purpose for existing and a clear definition of the scope of what the service does. If done properly, services will be composable, meaning that several services may be leveraged and composed to create new applications or services with minimal additional programming.

Services should be loosely coupled. This has two key implications. First, the service interface or contract should be independent of the implementation or application code used to fulfill service requests. Second, the contract should not expose any assumptions about the language or data representations used to implement the service request. In this way, service consumers aren't forced to process data types that may not be native to the language used to implement the consumer.

Services should be location-independent. Don't build assumptions into service providers or consumers as to the physical location of the service. This enables flexibility in moving where the service is hosted, routing requests to multiple instances of the service, or even substituting a different service implementation that might adhere to the same service contract. Instead, the Service Oriented Architecture SOA should leverage a service repository or registry where services can register themselves and where consumers can go to locate a service instance. (For more on registries, see The importance of a registry for a service-oriented architecture.)

Services should utilize models. One of the significant characteristics of an Service Oriented Architecture SOA is that services express themselves as models. Models define service capabilities and attributes as well as describe relationships between services. Models can also be used to describe the data being exchanged. This approach is powerful because models make it possible to transform data so that service consumers aren't necessarily bound to the data definitions exposed by the service provider. This freedom gives an Service Oriented Architecture SOA its ability to adapt and to enable rapid composition of services.

Key SOA service oriented architecture principles

Key SOA service oriented architecture principles

Several key principles can guide you as you plan to create an service oriented architecture SOA-based solution. First, remember this: When you begin applying service oriented architecture SOA principles, always do so with an eye toward a specific business domain. For example, in the above illustration, our domain was banking. When we design the services in this example, we'd typically design them to apply to this specific domain. But in some cases, the services will be useful in other domains as well.

Now let's look at the principles of designing an architecture by layers—evaluating the traits of services, and choosing the appropriate level of granularity for each service.

The architecture layers

When designing an architecture using service oriented principles, keep in mind that there are several key layers to the architecture. Each of these layers serves an important purpose. These layers are:

Service enablement: We can consider this first layer as the foundational layer. Many of the key services for the particular domain live here. In our example above, this is where we'll find services such as the checking account service, customer vault service, etc. Some of the enabling capabilities may exist here as well, such as application servers, management services, etc. But note that we don't really have an service oriented architecture SOA if we stop here. Instead, we may have a collection of loosely coupled components. In fact, it may be that these services aren't even loosely coupled. At this level, it may be tempting to simply build out applications using point-to-point connections to these services. Indeed, this is the way many web services applications have been built to date.

Service architecture: When we move to this next level, we can begin to realize the value of an architecture that is service oriented. Here, we'd include many of the architectural services that may be required for any service oriented architecture SOA-based solution. These are key services (discovery, transformation, security, orchestration, messaging and integration) that other services within the solution can depend on. We may also have some domain-specific services here that the other services can leverage. In the case of our banking domain example, such a leverage-able service might include an auditing service, important in banking because regulations require that all transactions are available for audit.

Service model: In this final layer, we can realize the real power of the service oriented architecture SOA approach. Here, we can begin describing the various services and their relationship to each other in terms of a model that can be stored, exchanged, and used to automate interactions, facilitate the creation of orchestrated services, and so on. This is also where we can begin to describe the relationship of services at the functional level to services as they may be understood by business entities that care more about service levels and semantics of the interactions than they care about which the language the service was implemented in or what business logic was written to realize the service. This is a significant part of service oriented architecture SOA because it allows us to use the same services while creating different models to define different service relationships for different domains or solutions.

What is the SOA life cycle?

What is the Service Oriented Architecture SOA life cycle?

The core IT assets of any organization include its data, legacy systems, line-of-business applications, packaged applications, and trading partners. Each of these resources is a service provider responsible for producing numerous highly specific outputs, such as inventories and customer data.

Service orientation ties together these disparate and autonomous sources of information, bridging a wide range of operating systems, technologies, and communication protocols. The process by which it does this is an iterative one of creating (“exposing”) new services, aggregating (“composing”) these services into larger composite applications, and making the outputs available for consumption by the business user.

Expose

The expose phase of the service oriented architecture SOA approach focuses on which services to create from the underlying applications and data. Service creation can be fine-grained (a single service that maps to a single business process) or coarse-grained (multiple services come together to perform a related set of business functions).

The expose phase is also concerned with how the services are implemented. The functionality of underlying IT resources can be made available natively if they already speak Web services, or can be made available as Web services though the use of an adapter.

Compose

Once services are created, they can be combined into more complex services, applications, or cross-functional business processes. Because services exist independently of one another as well as of the underlying IT infrastructure, they can be combined and reused with maximum flexibility. And as business processes evolve, business rules and practices can be adjusted without constraint from the limitations of the underlying applications.

Consume

Once a new application or business process has been created, that functionality must be made available for access (consumption) by either other IT systems or by end users. The goal of the consumption process is to deliver new, dynamic applications that enable increased productivity and enhanced insight into business performance. Users can consume the composed service through a number of avenues, including Web portals, rich clients, Office business applications, and mobile devices.

SOA Concepts

SOA Service Oriented Architecture Concepts

Architecture is not tied to a specific technology. It may be implemented using a wide range of technologies, including REST, RPC, DCOM, CORBA, Web Services or WCF. Service Oriented Architecture SOA can be implemented using one of these protocols and, for example, might use a file system mechanism to communicate data conforming to a defined interface specification between processes conforming to the service oriented architecture SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without the service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.

Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA Service Oriented Architecture. Prentice Hall, 2005

Service Oriented Architecture SOA Meta Model, The Linthicum Group, 2007SOA can also be regarded as a style of information systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services[citation needed]. These services inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service. Service Oriented Architecture SOA-based systems can therefore be independent of development technologies and platforms (such as Java, .NET etc). Services written in C# running on .NET platforms and services written in Java running on Java EE platforms, for example, can both be consumed by a common composite application. Applications running on either platform can also consume services running on the other as Web services, which facilitates reuse.

Service Oriented Architecture SOA can support integration and consolidation activities within complex enterprise systems, but Service Oriented Architecture SOA does not specify or provide a methodology or framework for documenting capabilities or services.

High-level languages such as BPEL and specifications such as WS-CDL and WS-Coordination extend the service concept by providing a method of defining and supporting orchestration of fine grained services into more coarse-grained business services, which in turn can be incorporated into workflows and business processes implemented in composite applications or portals[citation needed].

The use of Service component architecture (SCA) to implement Service Oriented Architecture SOA is a current area of research.

Source: http://en.wikipedia.org/wiki/Service-oriented_architecture