Service Oriented Architecture

What is SOA?

"SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by
a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners."

Why SOA?

Companies across many industries view IT infrastructure as a source of competitive advantage. To maintain an edge, they must quickly adapt business applications to respond to customer needs and market changes. This introduces a challenge for development teams: building applications that are powerful enough to deliver competitive differentiation, yet flexible enough to evolve with rapidly changing business requirements.

An SOA approach to application development aims to maximize the reach and adaptability of software systems. Business applications built using a service-oriented approach are flexible and extensible, making them easy to adapt to new business requirements.
Three of the main reasons companies are turning to SOA include agility, maintainability, and efficient development.

Agility Continual change is a fact of life in software and a major source of expense. This is particularly true of rigid, monolithic systems. The greatest benefit offered by the SOA model is the ease with which SOA applications can change to meet new requirements.
In the SOA model, an application becomes a grouping of discrete, independent services communicating through messages. These discrete services can exist anywhere within network reach and may be built upon a variety of technologies. When some part of the business problem changes, the solution is simply to swap-out one or more of these discrete services with services that meet the new requirements.
Each service that participates in an SOA application is a separate, independent unit of functionality that interacts with other participating services through a simple service application program interface (API). Ideally the API consists of one or more service operation methods implemented with a few lines of code. Taken together, these qualities make SOA applications very easy to extend and modify

Maintainability Another key benefit of an SOA approach is the maintainability of the business logic that under­lies the services comprising an SOA application. Because the service APIs serve as a buffer between the other services that make up an SOA application and the business logic that imple­ments any particular service, changes to the business logic that underlies a particular service should have no effect on the overall SOA application.
Stated another way, a service should encapsulate business logic in such a way that other services do not need to know anything about how it provides the service, only about what the service takes as input and returns as a response. If such encapsulation is achieved, those tasked with maintaining any particular business logic can make changes, even very major ones, without worrying that their changes will cause major pain to those who maintain other parts of the business logic, or who maintain the SOA application itself.

Efficient Development SOA applications are, by nature, highly modular. This modularity has positive implications for the development of SOA applications as well. Even a very complex SOA application is com­prised of a number of autonomous services. Each service can be designed and fabricated sepa­rately by the developers who best understand the particular functionality. The developers work­ing on a service have no need to interact with or even know about the developers working on the other services that comprise the application.
The fact that the development of SOA applications consists of many distinct, relatively small, and largely independent tasks favors the use of small, focused, efficient development teams. Also, because SOA applications are modular and agile, they can be developed and deployed in a series of small steps. Often a reasonable subset of the full functionality can be developed and deployed quickly, which has obvious time-to-market advantages. Additional functionality can readily be added in planned stages until the full feature set has been realized.

SOA principles
The following guiding principles define the ground rules for development, maintenance, and usage of the SOA
· Reuse, granularity, modularity, composability, componentization, and interoperability
· Compliance to standards (both common and industry-specific)
· Services identification and categorization, provisioning and delivery, and monitoring and tracking
The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behavior of a system and the style of its design:
· Service Encapsulation - separation of concerns and information hiding, in software engineering, the process of enclosing programming elements inside larger, more abstract entities.
· Service Loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
· Service contract - Services adhere to a communications agreement, as defined collectively by one or more service description documents
· Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world
· Service reusability - Logic is divided into services with the intention of promoting reuse
· Service composability - Collections of services can be coordinated and assembled to form composite services
· Service autonomy – Services have control over the logic they encapsulate
· Service optimization – All else equal, high-quality services are generally considered preferable to low-quality ones
· Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
SOA and web service protocols
SOA may be built on Web services standards (e.g., using SOAP) that have gained broad industry acceptance. These standards (also referred to as web service specifications) also provide greater interoperability and some protection from lock-in to proprietary vendor software. One can, however, implement SOA using any service-based technology, such as Jini.
Service-oriented architecture is often defined as services exposed using the Web Services Protocol Stack. The base level of web services standards relevant to SOA includes the following:
XML - a markup language for describing data in message payloads in a document format.
HTTP (or HTTPS) - request/response protocol between clients and servers used to transfer or convey information
SOAP - a protocol for exchanging XML-based messages over a computer network, normally using HTTP
XACML - a markup language for expressing access control rules and policies.
Web Services Description Language (WSDL) - XML-based service description that describes the public interface, protocol bindings and message formats required to interact with a web service
Universal Description, Discovery, and Integration (UDDI) - An XML-based registry to publish service descriptions (WSDL) and allow their discovery.

An SOA - Constituent Parts
To determine what the constituent parts of an SOA are it is first necessary to break down the question into the design-time and run-time requirements. We will look at the two separately, and then propose a single view of an SOA by combining them.
The idea that SOA encapsulates both design-time and run-time (and is really about both physical and logical architectures) is critical to understanding SOA.

SOA Design-time requirements
UDDI directory of External web services
UDDI (Universal Description, Discovery and integration) provides the definition of a set of services supporting the description and discovery of:
· Businesses, Organizations and other web service providers
· The web services they make available and
· The technical interfaces which may be used to access those services.
UDDI’s, like phone books, are used to discover organizations and the web services they offer. In an SOA environment this would be a directory of external web services already being used by the
enterprise. Of course, any external web services not currently being used by an enterprise would still be available in the appropriate external UDDI and could always be accessed from there. The idea is to use this UDDI as a register to aid the design process.

Directory of Enterprise Internal web services
Similar to UDDI, but containing those web services published by the enterprise itself. This internal directory would indicate whether the web service is externally available also. This would help developers and designers to re -use available web services when designing new business processes.
The directory needs to cross -reference the web service to the organisations and processes it is currently being consumed by.

Agile Design Methodology
An agile design methodology is one which is standards oriented, ensuring lowest possible TCO and enabling best re-usability. The key standards in this case are for language (XML-based, SOAP compliant),
Web services definition (WSDL) and business process modeling (BPML / BPEL4WS). It is a methodology which is oriented towards re-use, with re-usability a key design paradigm at all times.
Because the nature of SOA is of a series of quick, fast-ROI, business focused projects (each delivering a part of the overall SOA framework) there will at any given time be a number of parallel projects running. The design methodology needs to emphasize the requirement for cross-project information and working.
An agile design methodology should also not be too proscriptive regarding the actual development technique (for example Extreme Programming can be a valid approach); it should instead focus on
the deliverables.

Process Driven Development
Development based upon the modelling or re -modelling of business processes. The start point should be the expansion or re-working of the set of modelled business processes. Each business process can itself become a new web service, enabling the whole business process to be re-used by other processes or channels.
The creation of web services should be driven by the process or process part which needs to consume the web service. This is key; progression to an SOA means exposing functionality only as required rather than as a “Big Bang” approach. Obviously the main body of work for new web
Services will be the creation of the web service itself which can be drilled into from the business process flow.
A main feature of this style of development is the orchestration of new business processes via underlying (possibly pre -existing) web services. The orchestration should be supported by the toolset, and should be captured using one of the two key standards in this area (BPML/BPEL4WS).
This ensures continued re -usability in the event of new or extended development toolsets being adopted.
The flexibility to design new (composite) applications/processes is traditionally thought of as application server functionality; one of the key benefits of SOA is the empowerment of business functions to have greater control over the implementation of the business process.
Another reason for the standards oriented approach is that business process modelling no longer ends at the edge of the enterprise. Increasingly the extended processes are being modelled; shared
With partners in a common and standard format, the collaboration is greatly enhanced and success is much more a likely proposition.


Workflow Oriented Development
One of the key paradigms for SOA development is that the business processes are seamless. Each step in each process should be linked, either as an automatic next step (workflow or flow driven),
Or as a workflow task on a users’ consolidated task list. Equally cross -process interactions are often workflow driven – especially where there are decision points. Business processes are not just modelled, they are orchestrated.

Multi-level Design Management
SOA delivers the challenge of creating an agile development and implementation environment, whilst retaining good project control and an overview of the overall SOA implementation roadmap.
Design management must be based primarily on the business objectives each project is to deliver, but also must include the following:
· Step-by-step approach to create building blocks (components)
· Overall programme management to retain the overview of all parallel projects plus the
· overall roadmap
· Driving the need for easy integration at all levels – content, information, process and
· application as key design criteria
· X-Project control, planning and co -ordination
· Release management

Agile Toolset for SOA Development
The toolset itself must also be agile in order to deliver or facilitate the following:
· Abstraction of existing application functionality into new web services
· Minimize coding, yet able to link to disparate systems with disparate communications styles,
· databases and interfaces
· Ability to plug in existing middleware interfaces
· Standards based, with good upgrade paths to transform into latest versions of standards and convert between versions
Any SOA solution will thrive or shrivel based on the agility of the delivered toolset. If development often means coding, and if changes to versions of standards (especially for XML industry-specific messaging definitions) means re-working rather than simple conversion or upgrade, then the solution is not really agile and will always inhibit agile implementations.

Whilst most parts of a business process can be abstracted as discrete web services, it will also be true (at least initially) that there will be requirements to build message -based interfaces underlying the process flow. Typically this will be true in the short-term where such interfaces already exist, or where the flow starts by the extraction of data independently of the data creation (e.g. batch extractions). These can be built as separate components which can be attached to the relevant business process step and are then, themselves, re-usable web services.

Information Routing Modelling
The complete SOA concept is not just about agile business processes; it also incorporates the need to integrate information and to deliver this information to the right people at the right time. As with business processes, this integration is not just about internal information, but will often include information from external sources. The SOA solution must also be able to model the flows of information across the enterprise and the extended supply chain.

Debugging and Simulation Capability
It is true for all development tools that the availability of good debugging and simulation tools will greatly facilitate the fast delivery of robust and reliable solutions. Any SOA solution should provide
capabilities for debugging process steps, whole processes, and cross-process flows, as well as simulation to support performance testing.

Multi-Language Capability In order for an SOA solution to be deployed globally it must support multiple code page and multiple language scenarios. This may be in the form of separate application or database servers, Unicode capability, or separate presentation layers.

SOA – Run-time requirements
Run-time SOA is characterized by the need for visibility of flows, errors and bottlenecks. It is further characterized by the need for single point sign-on and enterprise identity management.
Run-time flows fall into two categories: the business process flow and the underlying integration flow.
The latter is the extraction, handling and routing of data from one system to another which is triggered by the business process.

Consolidated Process Management
A key criterion for the run-time portion of an SOA solution is the ability to present transactional and information flows visually by business process, organizational unit and server. This will not only facilitate monitoring, collection of business activity data and error recognition but will also help to identify performance bottlenecks. The SOA solution should include a management console which will allow / facilitate the following:
· Visibility of flows by process, organizational unit and server
· Visibility of the underlying interface flows where relevant
· Alert handling
· Collecting data on activity monitoring at process, organizational unit and server levels
· Capacity and volume visibility
· Bottleneck / performance visibility

Process Oriented Monitoring and Administration Tools
The run-time environment should display information also at the business Process level and allow activation / de-activation of any process (or stopping the process at a specific step) as a means of
handling problems / implementation. Transactional information (underlying messages where relevant) should also be available by drilling into a specific process.

Business Activity Monitoring (BAM)
The SOA tool-set should include BAM capability; the run-time environment should feed data to the BAM module to support this.
Persistence of Message-Based Asynchronous Process Data
SOA requires a data store external to the applications that provide the underlying functionality, akin to an Operational Data Store, to store potentially long-term but essentially transient process related data.
Whilst some processes will be synchronous, and may be online (driven from the user task list or an external web service for instance), others will be asynchronous and message-based. The ability to store data after each step in a flow (both process flows and the underlying technical integration flows) is critical to the ability of an SOA solution to guarantee delivery, to support store and forward, and to manage long -duration business processes.
This data should store the operational context of the process such that the process can be restarted, monitored, analyzed and debugged as necessary.
Alongside this transient operational data the process model meta-data (process definition, routing and transformation rules) also needs to be stored.

Scalability of the Environment
Given the building block approach of SOA implementations it is critical that an SOA solution is entirely scalable. Scalable really means that the toolset supports the deployment of further servers, the assignment of specific processes or organizational units to servers and the
management of software across servers.
Typically an SOA might start with one organizational unit handling one Business Process via the SOA environment (single server plus resilience) and will migrate to Enterprise wide processes. The SOA toolset must be capable of seamless deployment of further servers (without significant
Business impact) underpinned by the secure management of software across all servers.

Resilience
As for any other IT architecture, a Service Oriented Architecture must provide sufficient resilience to support the business. The SOA run-time environment must facilitate this via enterprise-wide alert handling and, if possible, the ability to target process flows on a specific server (or server group) as a fall-back (prioritization of flows).

User Access and Security
One of the ways in which SOA can empower a workforce is the creation of single -point sign on. The SOA solution should offer a browser-based, role -oriented experience for the user which incorporates task lists based on the users’ roles and the relevant collaboration and knowledge
content as well as links to the key web sites for the role. The most critical parts of this are the concepts of enterprise-wide identity management and federated identity management (across enterprises) which allow the user to sign on once and for the appropriate access to be given in any application/task the user can access.
Given that an SOA environment inevitably will communicate both across the internet and intranet, the set-up of appropriate firewalls to control external (internet) access is a critical factor as for any system which needs to allow external access.

Workflow
Availability of work -flow functionality in any SOA solution facilitates the following;
· Linking into the underlying applications where necessary (it is a utopian concept to imagine that ALL processes, across the whole enterprise, will be abstracted into web services – some processes may remain within the application)
· Browser-based task lists for the users

Event driven
The link between processes (or between a process and the external world) will often be in the form of an event (e.g. order created, error detected, document released). An SOA solution which supports event handling and allows process modelling to incorporate event handling can be thought of as more agile than one that does not.

Simulation capability
The ability to simulate traffic across any process is very useful when reviewing performance and scalability questions.

Error Management
A key criterion for any SOA run-time environment is its error management. The criteria for error management are;
· Visibility of errors
· Re-start capability
· Error notification
· Workflow linking

SOA Elements

Industry Background

For several years now, SOA, or services-oriented architecture, has promised to deliver unprecedented flexibility and cost savings to IT, by defining a methodology for the use and re-use of software components and business processes. However, SOA is still new, and organizations are still in the process of learning how to implement it so that it fulfils its potential for intra and inter-enterprise services reuse and process interoperability. Meanwhile, would-be SOA practitioners encounter the challenges typical of a software methodology that is not yet supported by a fully mature industry.

For example:
• Every major vendor claims to have adopted SOA and has published its own view and reference architecture for SOA. SOA start-ups are being acquired by larger vendors, creating further volatility

• IT typically does not communicate effectively to the business how money spent on SOA will automate business functions and deliver solutions cheaper, better, and faster

• Every major standards body has multiple groups attempting to define SOA, adding to the confusion and slowing adoption of SOA.

• Development and management tools are not sufficient

• A lack of common vocabulary across the industry has made it difficult to share best practices.