Characteristics of a Service Oriented Architecture

Iryx Limited, The Heath, Runcorn, Cheshire, WA7 4QF

Tel: 01928 515835 Fax: 01928 511391 http://www.iryx.com

© Iryx Limited, 2004

Characteristics of a Service Oriented Architecture

Author: Paul A Moore

Background.

In as concise a definition as any, Dr Hao He said that "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."i

Since the evolution of the SOA concept almost 30 years ago, and its early incarnations in DCOM and especially CORBA, the IT world has changed dramatically. The emergence of Web Services and XML has not only re-energised SOA, but has also heralded the coming of new architectural requirements, challenges and opportunities.

Gartner’s vision for web services and SOA solutions involved the ‘Four-Platform Framework’. This comprised of a web services producer platform, a web services provider platform, a web services consumer platform and a web services management platform.

A recent article published by Schmelzer and Bloomberg ii offered the ‘SOA Implementation Framework’ concept. This is much closer to today’s SOA reality in that it recognizes the need to think of SOA both in design-time and run-time dimensions, and moves away from the abstract concepts of web service production and consumption to the real challenges of tools, integration, processes, management and security.

However, even this approach is limited in that it does not attempt to apply real world characteristics to the SOA implementation framework. Applying these characteristics will allow anyone (vendors, end-users and consultancies) to overlay real life examples to validate any SOA solution and identify both where it meets the challenges and where it fails to meet them.

This paper attempts to take the process down a level; to identify those detailed characteristics of a Service Oriented Architecture. This will not be definitive; indeed, just as SOA and web services continue to evolve, the definitions we apply to explain, develop and manage them must also.

© Iryx Limited, 2002 2 of 10 30

Registered in England, Company No 04280864.

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, a nd 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:

o Businesses, Organisations and other web service providers o the web services they make available and o the technical interfaces which may be used to access those services.

UDDI’s, like phone books, are used to discover organisations 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 modelling (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 emphasise 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:

o Step-by-step approach to create building blocks (components) o Overall programme management to retain the overview of all parallel projects plus the

overall roadmap o Driving the need for easy integration at all levels – content, information, process and

application as key design criteria o X-Project control, planning and co -ordination o Release management

Agile Toolset For SOA Development

The toolset itself must also be agile in order to deliver or facilitate the following:

o Abstraction of existing application functionality into new web services o Minimise coding, yet able to link to disparate systems with disparate communications styles,

databases and interfaces o Ability to plug in existing middleware interfaces o 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 pro cess 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 characterised by the need for visibility of flows, errors and bottlenecks. It is further characterised 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, organisational 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:

o Visibility of flows by process, organisational unit and server o Visibility of the underlying interface flows where relevant o Alert handlin g o Collecting data on activity monitoring at process, organisational unit and server levels o Capacity and volume visibility o Bottleneck / performance visibility

Process Oriented Monitoring And Administration Tools

The run-time environment should display info rmation 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 technica l 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, analysed 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 scaleable. Scaleable really means that the toolset supports the deployment of further servers, the assignment of specific processes or organisational units to servers and the management of software across servers.

Typically an SOA might start with one organisational 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 (prioritisation of flows).

User Access And Security

One of the ways in which SOA can empower a workforce is the creation of single -point signon. 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;

o Easy linking of processes / process parts



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)

o 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;

o Visibility of errors o Re-start capability o Error notification o Workflow linking



Consolidated SOA

Looking at both the design -time and run-time criteria, a Service Oriented Architecture is therefore one which provides an agile development toolkit (including the ability to create new business processes - or composite applications), is process driven both in design and run-time, supports enterprise-wide visibility of the run-time environment, is also workflow driven and incorporates portal-based single user sign-on and identity management. All of this backed up by a clear programme management and an agile design methodology.

In other words, it is not realistic to think of an SOA in only design-time or run-time dimensions. An SOA must provide both sets of criteria, and must be backed up by an effective design and programme management methodology.

SOA architecture

Desi

gn T

ime

Run T

ime

Programme and Development management

Process-drivenDevelopment toolkit

Internaldirectory

EnterpriseManagement

Business ProcessControl

Persis-tence

Workflow

Eventhandling

User Access & Security

BAM

( B

usi

nes

s Act

ivity

Man

agem

ent)

activity

Underlying applicationsExt

ernal

W

eb-s

ervi

ces

UDDIdirectory

This architecture should be overlaid by the classical 3 -tier architecture of development, QA and production environments and supported by development control tools such as publishing, version control and release management.



SOA Layers of Integration

Another way of viewing a Service -Oriented Architecture is to use the concept of layers. An SOA can then be thought of as having 5 distinct layers as per the diagram below.

In the people integration layer, the user accesses the role-based portal which delivers the required collaboration, information, content (unstructured information) and tasks lists as per the role definition.

Delivery of the content and information is achieved via the information integration layer.

The task lists which comprises the outstanding tasks awaiting the user based on their role is delivered from the process integration layer.

The actual interaction with the underlying application layer, both in terms of information delivery and process execution is handled by the technical integration layer.

Underlying applications

Ext

ernal

Web

ser

vice

s

Portal, Role-based access

User PortalRole-based access, tasks and collaboration

ContentIntegration

Technical Integration

ProcessIntegration

Information Integration

Peo

ple

Inte

gra

tion

La

ye

r

Info

rmati

on

Inte

gra

tion

Layer

Pro

cess

Inte

gra

tion

Layer

Tech

nic

al

Inte

gra

tion

Layer

Ap

plica

tion

Layer

SOA – Layers of Integration



Extended SOA – some expansion concepts.

Currently, we think of SOA as being, first and foremost, the vehicle for abstracting and enabling the management of business processes. Indeed, the key promise of SOA is one of abstraction of business processes to provide the environment to create real business agility. However, agile BPM (BPR) is only one strand of business flexibility.

I think of business agility in terms of:

o Business Process Management o Business Information Flow management o Business Organisation Management

In other words, it is equally important for the business to have visibility and control over its information flows and organisation model.

Information flows.

The abstraction, visibility and control of an enterprise’s info rmation flows (and flows from/to external Enterprises) is also critical to a business. Flexibility in defining information flows enables new KPI’s (Key Performance Indicators) to help drive business decisions and helps the business focus the information available to the enterprises human resources.

Organisation Management.

There is much written (and said) today about the inevitability of SOA commoditising back-office systems. The reality, it seems to me, is that the back office systems will still have, and will still be managing, the enterprises organisational model. Typically, managing the enterprise organisational model is a configuration exercise in all systems. This can be translated into standard system change management and software control which, in turn, can be translated into a 2 -3 month project, having to go through QA, Integration and regression testing.

The ability to extract the business organisational model out of the underlying systems (while remaining linked to the organisational concepts in each underlying application via services) will mean that new business organisation units can be added in an agile way, without a major IT project. The same would apply for the de-merger of a business unit of course. The business organisation model would need to be available across the enterprise and at a detailed level (e.g. Sales Force/Organisation, Manufacturing units, Warehousing, Cost centre hierarchies and Charts of Accounts). Ideally, any new business unit would be able to be based on an existing unit, with the ability to tailor the copy before publishing the organisation down into the underlying systems.

I see this not only as the great enabler of agility, but also as the biggest hurdle between IT and business agility.

© Iryx Limited, 2002 10 of 10 30/


Conclusion

It is necessary to think of Service Oriented Architectures in a number of ways. In terms of delivering design and run-time environments, the key characteristics of process orientation, an agile development toolkit and enterprise wide run-time management are underpinned by effective programme management and an agile development methodology.

An SOA can also be thought of in a more abstract way; as an environment which delivers service-based integration at application, process, information and people level.

Further, the definit ion of SOA today is significantly different than that of 25 years ago and I would expect the definition to further evolve. I believe it to be a logical step for SOA eventually to encompass both information flow management and organisation management. Even this is unlikely to be the end-point. Because SOA is an evolving concept which is being shaped by emerging standards and technologies the definition of what SOA encompasses will also, inevitably, continue to evolve and to expand.

i What is Service-Oriented Architecture? Dr Hao He, Sep 2003, http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html ii Retiring the Four-Platform Framework for web services, Ronald Schmelzer and Jason Bloomberg, Mar 2003, http://www.zapthink.com/report.html?id=ZAPFLASH-12032003

Characteristics of a Service Oriented Architecture

Documents

Transcript of Characteristics of a Service Oriented Architecture