Service-Oriented Architecture "defined and explained by Samih Fadli"

The Role of an SOA Governance

2005-09-27T16:56:00.000-04:00

Over the past two decades, applications and their supporting infrastructures have become exceedingly complex, with many points of failure due to brittle architectures and tightly-coupled integrations.

“SOA” is arguably the most recognizable acronym in IT these days. This is because SOA has the potential to enable a much higher degree of business agility by transforming enterprise IT based on a service-driven delivery model.Unlike traditional application architectures, SOA is designed for change. Applications and systems based on SOA become flexible “plug-and-play” IT assets that can be quickly and easily re-purposed as the demands of the business evolve.

The definition of the word governance implies the action or manner of governing.SOA governance, introduces the notion of domain ownership, where domains are managed sets of Services sharing some common business context. In many cases these sets of Services are business Services, such as customer information, order processing, or product analysis. Each domain is responsible for maintaining the applications that support its Services and for maintaining the interfaces to its Services for other domains.

SOA governance is the set of solutions, policies and practices which enable companies to implement and manage an enterprise SOA. SOA governance addresses many challenges and makes it possible to realize ROI and the business benefits of loosely coupled services..

The main areas of governance include the following:

Strategic alignment focuses on the imperative to align the business vision, goals and needs with the IT efforts.
Value delivery focuses on how the value of IT can be proved through results like profitability, expense reduction, error reduction, improved company image, branding, and so on.
Risk management focuses on business continuity and measures to be taken to protect the IT assets.
Resource management focuses on optimizing infrastructure services that are a part of the On Demand Operating Environment (ODOE -- see Resources) or other environment supporting the application services.
Performance management focuses mainly on monitoring the services that run in a enterprise's ODOE or other environment.

Any implementation of governance should be centered on the four pillars of an enterprise architecture: people, processes, technology, and services. One mechanism to implement an enterprise IT and SOA governance is by establishing a center of excellence (CoE) for IT and SOA governance that would enable a shared resource and capability center to function as a resource pool as new business application needs arise. A governance implementation needs to be supported by a hierarchical organizational reporting structure.

SOA Implementation Requirements

2005-09-24T00:15:00.000-04:00

An Service-oriented architecture provides the implementation patterns required to construct applications from loosely coupled services. In order to build such applications, an implementation environment should provide the following capabilities:

Definition of services independent of their implementation
Implementation and hosting of services as a provider
Location and usage of services as a consumer
Assembly of services from other services and business rules
Support for synchronous, asynchronous and conversational services
Orchestration of application presentation built on services and rules
Support for multiple forms of human interaction
Automated data transformation between disparate data structures
Provisioning of local and remote servicesSupport for simulating, testing and debugging of services

Top 10 SOA Considerations

2005-09-21T22:44:00.000-04:00

Interoperability
With Web Service protocols evolving rapidly their implementation across the diverse infrastructure is likely to raise issues of interoperability due to different versions and inconsistent implementations by vendors. I recommended that Infrastructure elements will need to be upgraded in parallel to avoid interoperability issues.
Performance
Web Service infrastructure will at least in the near term often constitute an additional layer of infrastructure, as opposed to replacement, impacting performance. However, this should only affect the Web Services themselves, not other messages and transactions passing through the same infrastructure element. I recommended to introduce a parallel infrastructure elements dedicated to Web Services to ensure existing operations are not affected.
Granularity of Service
It is important to design the service interface with the proper level of granularity. Because you want your application to perform well, you should design Web services to be coarse-grained than individual session beans. A good way to achieve a coarse-grained interface is to design the Web service around the documents it handles, since documents are naturally coarse grained. You can apply these principles by exposing Web services that primarily exchange well-defined documents "eg.: purchase orders or invoices". These Web services may call multiple session bean methods to implement the services’ business logic..
Passing Parameters as XML Documents or Java Objects
A SOAP client invokes a service’s functionality by calling the appropriate WebMethod on the service interface and passing the expected parameters. Parameters may be passed as either XML documents, which are represented as SOAPElement objects in the service interface.
Layering the Service
Normally, it’s best when designing a service to separate the service’s interaction layer from the business logic processing layer. This is especially true when an incoming request uses a different data model than the data model used by the business logic. Recall that a service may divide its processing into layers if it handles requests that require significant pre-processing or when there is extensive mapping between the internal data model and the incoming data.
Delegating to Business Logic
After receiving and pre-processing a request, the endpoint must next map the request to the appropriate business logic and delegate it for processing.
Publishing Web Service Details
A Web service endpoint is described by its WSDL file, and clients of the service need access to the WSDL to obtain basic information about the service. One way to disseminate this information to clients is to publish the WSDL files in a Web Services Registry (WSR/UDDI), if the service is open to the general public.
Managing Complex Web Service Interactions
An application may have multiple interactions with the same Web service, it may access different Web services, or it may expose many Web service endpoints. There may be different types of interactions. An application may be both a service and a client. A service endpoint may receive documents of multiple types and hence needs to handle them accordingly. All this makes for complexity in managing Web service interactions. Message-level metadata and a canonical data model are common helper strategies that support complex interactions, and they are good building blocks for adding functionality to a Web service message exchange. By consolidating Web service endpoints, wean make an application’s Web service interactions more manageable.
Consolidating Web Service Interactions
Consolidating Web service interactions is a good way to simplify the complexity of a Web service application. What starts as a straightforward Web service application with basic interactions between a client and a single service often grows into an application that exposes more endpoints and may itself act as a client to other services. The application communication becomes more complicated, and the business logic often becomes closely tied to a particular service. When the number of Web service interactions grows beyond a certain point, you may want to factor out common code for reuse.
Building More Robust Web Services
Both .NET and J2EE platforms conform to the WS-I Basic Profile standards. Conforming to these standards means that the platform uses HTTP as the underlying transport for Web service calls. Unfortunately, from a business communication point of view, the HTTP protocol provides only a low-level degree of robustness. To illustrate, HTTP has no automatic retries to re-establish a connection that disconnects. If the receiving end fails, the entire HTTP call fails and there is no attempt to connect later. This low-level degree of robustness is not necessarily bad, since it means that HTTP can accommodate the participation of all kinds of systems and networks in a distributed Internet environment. HTTP is also a fairly simple protocol that any system can implement with a reasonable amount of effort. Despite using more reliable hardware and software systems and communication links, enterprises have no guarantee against failures. Failures may occur during a Web service request between a SOAP client and a Web service that may leave an application in an ambiguous state.

The key pillars of an SOA’s success

2005-08-19T12:00:00.000-04:00

Although a wide variety of factors determines the success of enterprise’s SOA strategy, four (4) pillars for success can be underlined and highlighted.

1. Organizational Alignment

The extent to which an organization has aligned their business and technology strategies is a key determinant of SOA readiness. It is important to evaluate the business strategy for well-defined business services and processes, and it is also critical for the success of an enterprise’s SOA strategy to secure a budget and to have an organizational alignment with respect to a funding model. Organizations with funding models that facilitates cross-unit cost sharing are typically much more successful in migrating to SOA enabled space than those with more inflexible funding models.

A flexible funding model is required and needed to compensate for initial overheads caused by applying SOA principals. Overheads are caused by different factors. The project team members have to familiarize themselves with new SOA standards, patterns and processes. However, the initial overhead is caused by the efforts required to increase reusability.

In addition, the choice of a suitable project piloting the implementation of the enterprise SOA is a critical factor for the success of an enterprise’s SOA strategy. It is very important that chosen project should be as visible as possible. However, this does not necessarily mean that it has to be prestigious. Ideally, the SOA projects should run no longer than one or two years, with a first delivery after six months.

2. Setting Up a SOA Swat Team

Such a team should focus exclusively on how best support and establish the SOA in the organization. The SOA Team will therefore have to contain evangelists whose task it is to explain the benefits of an SOA to the different departments and this initiative includes helping target audiences to gain an understanding of key SOA architectural principles, concepts, best practices, and technologies as well as the support in the actual implementation of these principals.

3. Methodology and Process

Adoption of an iterative methodology is critical to support quick, efficient, service-oriented analysis and to design lifecycle activities that complement SOA. Also, formal governance and operations
procedures make an organization more likely to adapt to SOA. New techniques for model-driven architecture (MDA) that heavily involve visual business process and service interaction modeling approaches are beginning to emerge, and are also important to evaluate. Examples of SOA success factors pertinent to methodology and process include:

Governance Model — Policies and procedures for the identification of necessary services,
coordination of complementary or conflicting service development efforts, and full lifecycle management of services from proposal to support
Model-Driven Architecture (MDA) — Familiarity and/or usage of emerging approaches and technologies that enable development of service-oriented models to facilitate interaction and communication of requirements and logic between business analysts, architects, developers, and testers.

4. Technology and Tools

SOA success is highly correlated to the choice of technology and tools utilized in both design-time and run-time environments, as well as the way in which those technologies and tools are designed to interplay to deliver a true service-oriented solution.

In the design-time environment, SOA readiness is impacted by how well the integrated development environment (IDE) extends to support rapidly emerging SOA implementation standards, especially Web services protocols. Design, development, testing, and deployment tools must support unique protocols and attributes of SOA, and critical infrastructure is necessary to support publication and discovery of new and existing services.
In the run-time environment, SOA readiness demands an infrastructure that supports secure, interoperable, and reliable messaging between services, and is capable of orchestrating service interactions to support business process demands.

Choosing the appropriate tools and technologies is not sufficient to achieving SOA success alone. The use of appropriate design and message exchange patterns is critically important. These enabling patterns allow organizations to deliver and utilize services in a repeatable manner to ensure consistency and adherence to best practices necessary to scaling SOA across the organization.

Recommended approach

Any organization’s strategy for moving to SOA should involve the following four (4) major activities:

Education — Gain an understanding of key SOA architectural principles, concepts, best practices, and technologies.
Assessment — Determine the current state of your organization’s readiness for moving to SOA by identifying existing best practices and gaps, as well as major opportunities for realization of benefits from SOA.
Planning — Develop a phased SOA migration plan that makes sense for the organization, mitigating business and architectural risks while measuring and delivering significant return on investment (ROI) through increased flexibility and responsiveness to changing market demands, as well as decreased design, development, integration, and support costs.
Execution — Deliver prototypes, pilots, infrastructure, and services consistent with the phased SOA migration plan, seeding and embedding SOA perspective and best practices
throughout the business and technology groups within the organization as well as among key customers, partners and suppliers.

Hidden SOA Challenges

2005-08-18T19:09:00.000-04:00

The service-oriented architecture (SOA) is not new, but it is rapidly emerging as the premier integration and architecture framework in today’s complex, heterogeneous computing environments. While the concept of SOA has existed for years, there were few standards that enabled open, interoperable, non-proprietary integration solutions.

Today, many software vendors are moving at a frenetic pace to support SOA. Web services and SOA are not equivalent; however, SOA realized using Web services is generating new found excitement in the integration world. Additionally, organizations must understand that SOA is not realized by merely flipping a switch or porting your existing services to some vendors software platform. For long-term success, companies must put SOA in their IT “DNA” and develop an overall SOA strategy that aligns their IT and business goals.

Since SOA is based on open standards and is frequently realized using Web services making sense of the WS-Specifications, which may add to the confusion of how to best utilize SOA to solve business problems. Additionally, many companies face the challenge of how to best utilize SOA to solve their business problems.

Organizations should be aware of several important SOA realities to dispel any myths or misunderstandings regarding the best approach to a smooth transition to SOA, including:

SOA is an architectural approach that has been around for years (eg: JINI, DCOM). While there are new ways to realize SOA, including the use of Web services technologies, leveraging the experience of a services organization well-versed in SOA is essential to understanding technologies and techniques necessary to gaining the business benefits of SOA.
SOA is more than just developing and deploying software. Organizations must evaluate their funding and governance models, analysis and design techniques, development methodology, deployment and support plans.
Web Services (XML/SOAP) are the preferred way to realize SOA.
Moving to an SOA enabled infrastructure should be done incrementally, but requires a shift in how we architect and compose services-based applications while maximizing existing technology investments and this requires a shift in how we compose service-based applications while maximizing existing IT investments.
Software Vendors have recognized the challenges customers face in moving to SOA and have developed several SOA service offering that leverages years of experience in delivering enabling technology solutions that met the unique needs of each customer.

Recommended Approach

Any organization’s strategy for moving to SOA should involve the following fourmajor activities:

Education — Gain an understanding of key SOA architectural principles, concepts, best practices, and technologies

Assessment — Determine the current state of your organization’s readiness for moving to SOA by identifying existing best practices and gaps, as well as major opportunities for realization of benefits from SOA

Planning — Develop a phased SOA migration plan that makes sense for the organization, mitigating business and architectural risks while measuring and delivering significant return on investment (ROI) through increased flexibility and responsiveness to changing market demands, as well as decreased design, development, integration and support costs.

Execution — Deliver prototypes, pilots, infrastructure, and services consistent with the phased SOA migration plan, seeding and embedding SOA perspective and best practices throughout the business and technology groups within the organization as well as among key customers, partners and suppliers

Understanding SOA

2005-08-17T15:23:00.000-04:00

Looking around we see the term or acronym SOA becoming widely used, but there's not a lot of precision in the way that it's used. The World Wide Web Consortium (W3C) for example refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. We see similar definitions being used elsewhere; it's a very technical perspective in which architecture is considered a technical implementation. Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services.

A service-oriented architecture is an information technology approach or strategy in which applications make use of (perhaps more accurately, rely on) services available in a network such as the World Wide Web. Implementing a service-oriented architecture can involve developing applications that use services, making applications available as services so that other applications can use those services, or both.

The components of a Service-Oriented Architecture include:

Service providers. A service provider is a component or set of components that execute a business function in a stateless fashion, accepting predefined inputs and outputs.
Service consumers. A service consumer is a set of components interested in using one or more of the services provided by service providers.
Service repository. A service repository contains the descriptions of the services. Service providers register their services in this repository and service consumers access the repository to discover the services being provided.

Figure 1. Service-oriented architectural components

What are the implementation Challenges of SOA?

While designing and implementing a service-oriented architecture, a company faces up to eight key challenges. These challenges align to the steps in a typical project deployment plan:

Service identification. What is a service? What is the business functionality to be provided by a given service? What is the optimal granularity of the service?
Service location. Where should a service be located within the enterprise?
Service domain definition. How should services be grouped together into logical domains?
Service packaging. How is existing functionality within legacy mainframe systems to be re-engineered or wrapped into reusable services?
Service orchestration. How are composite services to be orchestrated?
Service routing. How are requests from service consumers to be routed to the appropriate service and/or service domain?
Service governance. How will the enterprise exercise governance processes to administer and maintain services?
Service messaging standards adoption. How will the enterprise adopt a given standard consistently?

Why SOA?

There are many reasons for an enterprise to take an SOA approach, and more specifically, a web services-based SOA approach. Some of the primary reasons in my opinion are:

Interoperability. The SOA vision of interaction between clients and loosely-coupled services means widespread interoperability. In other words, the objective is for clients and services to communicate and understand each other no matter what platform they run on. This objective can be met only if clients and services have a standard way of communicating with each other -- a way that's consistent across platforms, systems, and languages. In fact, web services provide exactly that. Web services comprise a maturing set of protocols and technologies that are widely accepted and used, and that are platform, system, and language
independent. In addition, these protocols and technologies work across firewalls, making it easier for business partners to share vital services.
Scalability. Because services in an SOA are loosely coupled, applications that use these services tend to scale easily -- certainly more easily than applications in a more tightly-coupled environment. That's because there are few dependencies between the requesting application and the services it uses. The dependencies
between client and service in a tightly-coupled environment are compounded (and the development effort made significantly more complex) as an application that uses these services scales up to handle more users. Services in a web services-based SOA tend to be coarse-grained, document-oriented, and asynchronous.
Flexibility. Loosely-coupled services are typically more flexible than more tightly-coupled applications. In a tightly-coupled architecture, the different components of an application are tightly bound to each other, sharing semantics, libraries, and often sharing state. This makes it difficult to evolve the application to keep up with changing business requirements. The loosely-coupled, document-based, asynchronous nature of services in an SOA allows applications to be flexible, and easy to evolve with changing requirements.
Cost Efficiency. Other approaches that integrate disparate business resources such as legacy systems, business partner applications, and department-specific solutions are expensive because they tend to tie these
components together in a customized way. Customized solutions are costly to build because they require extensive analysis, development time, and effort. They're also costly to maintain and extend because they're typically tightly-coupled, so that changes in one component of the integrated solution require changes in other components. A standards-based approach such as a web services-based SOA should result in less costly solutions because the integration of clients and services doesn't require the in-depth analysis and unique code of customized solutions. Also, because services in an SOA are loosely-coupled, applications that use these services should be less costly to maintain and easier to extend than customized solutions.

Service-oriented architectures are rapidly being accepted by the IT world as a sound, modularized approach for building and deploying services across the extended enterprise. However, practical implementation of these architectures requires careful planning. Interested enterprises must first make sure that they're geared up to implement and support them in the long-term.