Characteristics of a Service Oriented Architecture


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Characteristics of a Service Oriented Architecture

  1. 1. Iryx Limited, The Heath, Runcorn, Cheshire, WA7 4QF Tel: 01928 515835 Fax: 01928 511391 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 expl in, develop and manage them must also. a © Iryx Limited, 2004
  2. 2. 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 regist er 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 pro cess 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. © Iryx Limited, 2002 2 of 10 30 Registered in England, Company No 04280864.
  3. 3. 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 for mat, 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, da tabases 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. © Iryx Limited, 2002 3 of 10 30 Registered in England, Company No 04280864.
  4. 4. 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 ca n 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. © Iryx Limited, 2002 4 of 10 30 Registered in England, Company No 04280864.
  5. 5. 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 © Iryx Limited, 2002 5 of 10 30 Registered in England, Company No 04280864.
  6. 6. 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 © Iryx Limited, 2002 6 of 10 30 Registered in England, Company No 04280864.
  7. 7. 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 Design Time Programme and Process -driven Development Development toolkit management Web-services External Internal UDDI directory directory Enterprise Management Event handling Workflow Activity Management) Persis- tence BAM ( Business User Access Business Process Run Time activity & Security Control Underlying applications This architecture sh ould 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. © Iryx Limited, 2002 7 of 10 30 Registered in England, Company No 04280864.
  8. 8. 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. SOA – Layers of Integration Integration User Portal People Layer Role-based access, tasks and collaboration Portal, Role-based access Information Integration Content Layer Information Integration Integration Web services External Integration Process Process Layer Integration Integration Technical Layer Technical Integration Application Layer Underlying applications © Iryx Limited, 2002 8 of 10 30 Registered in England, Company No 04280864.
  9. 9. 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 9 of 10 30 Registered in England, Company No 04280864.
  10. 10. 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 ef fective 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, ii Retiring the Four-Platform Framework for web services, Ronald Schmelzer and Jason Bloomberg, Mar 2003, © Iryx Limited, 2002 10 of 10 30/ Registered in England, Company No 04280864.