download now


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
  • Services form a key Architectural Layer Integration is performed at various layers in IT architecture. At the Technology Layer integration is focused in how the operational infrastructure is connected. The Application Layer contains the applications and components deployed to the technology below. Here integration might consider how SAP ERP is connected to Siebel CRM for example. The challenge with integration at these layers is that is often focused on specific instances such as J2EE to .NET, or SAP to Siebel. If these change then the integration must change too. Assets integrated in this way are considered tightly coupled or hard wired. The Service Layer abstracts resources away from these layers. Instead of considering how SAP is connected to Siebel, the focus shifts to connecting Customers with Orders – regardless of the underlying implementation. Finally, in the Business Process Layer solutions are constructed that use the Services , not the underlying applications and technology. This is highlighted further when the requirement for business process optimization that spans multiple participants is considered – such as supply chain automation where the underlying application and technology layers might be divided across many participants. Integration is therefore difficult to achieve using traditional approaches at the technology and application layers as there is no common technology, application or integration platform . More importantly, change will happen independently within each participant. No participant will want to be constrained when making changes to their own implementations by the technology used by its partners, or the technology used for integration. So integration via the Service Layer becomes more important. Federation requires a Loosely Coupled approach that drives the need to use Web Service protocols as the common connectivity solution.
  • A key reason for using layers in any architectural approach is to constrain change to the appropriate layer and to minimize impact on the others. The Service Architecture helps to isolate change in the Providing or Consuming layers. For example, the frequency of change in the business process, or the device and technology diversity used in the consuming application might be more frequent than that in the core systems that are used to Provide the Services. The Service Consumer should not be interested in the implementation detail of the Service – just the Service provided. The Component Architecture could vary from Provider to Provider yet still deliver the same Service. Similarly the Provider should not be interested in the Composite Application Architecture that the Service is consumed in. New, as yet unforeseen applications should be able to reuse the same set of services. However, to enable this, Services must be carefully abstracted away from Implementation. Further Information CBDI Reports: CBDI Understanding SOA
  • We can combine the concepts discussed so far to show how several SOA layers help to separate concerns, provide flexibility by loose coupling, and enable different Services to be aggregated or composed into higher level Services. The providing Resources are first enabled as Implementation Based Services. The Business Service Bus then provides a useful layer of abstraction and composition that aggregates the low level Implementation Based Services into more meaningful Business Services for each Business Domain that can be reused across many applications. Finally the Composite Application that is delivered to support a business process provides a further layer of Composite Business Services that specializes the Business Services to users of the specific process. The Business Service Bus plays a key role in ensuring that the Composite Application and the Providing Resources are loosely coupled. Meanwhile the Enterprise Bus provides the infrastructure Services required to support all layers. Why are there so many layers in this architecture? Having these different layers enables Encapsulation Hide the detail in one layer from the next Virtualization Enable Provisioning options Federation Each layer can be a different participant Each layer may contain several participants Agility Loose coupling across layers Contain change, and rate of change within layer Separation of concerns Separate specialized solutions from generic resources Each layer can have different technology Each layer can have different ownership Further Information CBDI Reports: Composite Applications CBDI Presentations Essential Guide to Service Orientation
  • The Business Service Bus provides an organization with a functional view of their Services. The Enterprise Service Bus (ESB) provides an infrastructure view, in terms of the middleware layer that supports and manages the run-time business and infrastructure services, and facilitates their creation from existing assets. The run-time middleware layer to enable the business service bus, connect services to resources, and provide various infrastructure services to manage and facilitate the business services is commonly referred to as the Enterprise Service Bus (ESB) CBDI believes the ESB should be seen as an architectural layer of infrastructure services – and not just as an instance of a service enables middleware software product that provides these capabilities. For the same reasons as business services, infrastructure services should also be loosely coupled to the actual implementation. This might sound too purist a view for many organizations whose immediate requirements are still largely based on the reuse of existing systems, where middleware like MOM and EAI will remain essential technology for the foreseeable future. However, we see no reason why ESB cannot be seen as another layer that could leverage the capabilities offered by the MOM and EAI layers without creating tightly coupling to them. After all, Web Services and SOA are meant to free organizations from the tyranny of proprietary middleware, not further expand its use. The ESB should therefore be seen as something that complements existing middleware, and as illustrated is another layer in the overall enterprise SOA. The existing middleware and platform infrastructure plays a key role in service-enabling the existing application resources. But in the context of ESB, not only do they enable Business Services, they expose Infrastructure Services of their own. The extent to which a vendor chooses to package any of the middleware and platform resources into their ESB product is then an entirely separate decision. The ESB is not just consumed by the Process Orchestration layer of course, as it would also be available to developers building new Service implementations and other resources. Nor does it imply orchestration has to be performed by some orchestration engine – it could equally be a new process component built by a developer. An ESB implementation architecture could also follow a similar pattern to the pipeline we introduced in the Business Services Server report, with ISB components both exposing Infrastructure Services, and processing messages as they flow through the pipeline. Further Information CBDI Reports: Time to Board the Enterprise Service Bus? CBDI Business Services Server Report
  • SOA is inherently disruptive technology . However architectural implementation takes a long time, and capability is a function of architectural maturity. In the short, medium term most enterprises will restrict their activities to technical and integration applications. These generally require lower levels of sophistication in aspects such as message level and federated security, performance and management. The successful enterprise will plan its service application architecture as a series of maturity stages , each establishing foundations for the next stage. Further Information CBDI Web Services and SOA Roadmap Web Services Maturity Model
  • Over time, introducing SOA impacts right across IT and business domains. This requires proactive change management to ensure that application requirements are coordinated with infrastructure, process and resource capabilities. The CBDI Roadmap is a proven change management approach that guides enterprises in planning and managing the introduction of SOA. Further Information CBDI Web Services and SOA Roadmap Roadmap Planning
  • Jim Webber: Standards-based services are only good for specific verticals (including the WS infrastructure vertical). Otherwise you can happily create services with proprietary message exchanges which is after all what gives you business agility.
  • The SOA standards stack is important to define SOA for an organisation. It is important to develop and organisation view for SOA standards dthat can be communicated and followed within the organisations, and with vendors Focus on ratified standards only and avoid draft ones. Only use standards you need. There is a rapidly growing body of WS-* standards.
  • Jim Webber: XML is not self describing. XML Schema (or RelaxNG, or Schematron, etc) can be used to constrain message layout and content. Semantic Web technologies (e.g. RDF) can be used to describe semantics of messages or services in a much more limited fashion
  • Introduction of a standard interface to shared transaction services will reduce testing requirements. There is an opportunity to reduce the current development to testing ratio for “quarterly releases” from 1:9 to 1:3, which could greatly improve time to market.
  • download now

    1. 1. Putting SOA Into Perspective Hype & Hope vs Reality Kate Behan Kerandan Pty Ltd [email_address] ACS PD Board - Education Across the Nation - May/June 2005
    2. 2. ACS Certification Program Technology Trends Business Legal & Ethical Issues Business Strategy and IT Project Management Managing Technology & Operations Knowledge Management e-Learning Software Development Digital Business ACS Certification Program 2005
    3. 3. Updating Technology Trends <ul><li>Almost every futurist includes Service Oriented Architecture as a trend to watch </li></ul><ul><li>I needed to come to terms with SOA to update content for the Certification subject Technology Trends. </li></ul><ul><ul><li>Identified good introductory articles for the study guide, selected from a possible 151. </li></ul></ul><ul><ul><li>Selected a textbook from six possibles. </li></ul></ul><ul><ul><li>Devised an assignment which covers all related developments – we’ll look at that later. </li></ul></ul><ul><ul><li>Wrote an ACSLearn e-lesson which we’ll look at later. </li></ul></ul><ul><ul><li>Went to Ark Group SOA Conference in Sydney where I found some answers and more questions </li></ul></ul>
    4. 4. Where does SOA start? <ul><li>Terminology is misleading </li></ul><ul><ul><li>Web Services and all the WS-standards </li></ul></ul><ul><ul><li>Service Oriented Architecture </li></ul></ul><ul><ul><li>Services-Oriented Architecture </li></ul></ul><ul><ul><li>Can have SOA without web services and can use web services without an SOA </li></ul></ul><ul><ul><li>There’s also REST – Representational State Transfer. A method of building apps by sending XML documents using existing Internet protocols ( uses this approach) </li></ul></ul>
    5. 5. Back to the beginning <ul><li>It all starts with a desire to digitise business processes </li></ul><ul><li>Isn’t that we’ve all been doing for the past 30 or so years? </li></ul><ul><li>What’s new? </li></ul><ul><ul><li>The “Services” in SOA are business services </li></ul></ul><ul><ul><li>Services are linked together to implement business processes </li></ul></ul><ul><ul><li>Services are reusable and supplied or consumed by many </li></ul></ul><ul><ul><li>The really “new” bit is vendor agreement on standards (or nearly all vendors on some important standards.) </li></ul></ul><ul><ul><li>Connectivity and functionality are truly separated </li></ul></ul><ul><ul><li>Loosely coupled </li></ul></ul><ul><ul><li>Offers reusability at a higher level </li></ul></ul><ul><ul><li>Favours business flexibility over technical efficiency </li></ul></ul>
    6. 6. What is an SOA? <ul><li>Architecture that uses open standards to represent software assets as services </li></ul><ul><li>Standard way of representing and interacting with software assets </li></ul><ul><li>Individual software assets become building blocks that can be used in developing other applications </li></ul><ul><li>Used internally to create new apps out of existing components </li></ul><ul><li>Used externally to integrate with apps outside your organisation </li></ul>
    7. 7. More than technology <ul><li>“SOA is not just a services architecture seen from a technology perspective; it’s the policies, practices, and frameworks by which you ensure the right services and provided and consumed to provide business value.” </li></ul><ul><li> </li></ul>
    8. 8. SOA - NAB architecture team <ul><li>SOA is an application architecture within which key business functions are implemented as re-usable services with well-defined, invocable interfaces which can be called in a defined sequence to form business processes </li></ul><ul><li>Focus is on business processes </li></ul><ul><li>Business processes as services </li></ul>
    9. 9. Why SOA? NAB architecture team <ul><li>Easy for business to understand </li></ul><ul><li>Relatively easy to implement </li></ul><ul><li>Vendor support for standards </li></ul><ul><li>Lowers barriers to heterogeneous interoperability </li></ul><ul><li>Can expose functionality from legacy systems as services </li></ul>
    10. 10. The Hope <ul><li>Communicate with all business partners using just one universal set of protocols, documents and business processes </li></ul><ul><li>Loosely couple organisations so that they don’t need to know the internals of one another’s business processes or technologies </li></ul><ul><li>Change components without breaking anything </li></ul><ul><li>Respond to changing business conditions in a fast flexible manner </li></ul>
    11. 11. More hope <ul><li>Adapt functions and services to fit different business processes in an agile manner </li></ul><ul><li>Share data, information, and knowledge more readily through open standards and common protocols </li></ul><ul><li>Decrease infrastructure and people costs, reduce testing, fewer resources needed to manage IT </li></ul><ul><li>Simplify…….Leverage…….. </li></ul><ul><li>Support security-enhancing environments and identity management </li></ul>
    12. 12. Who’s moving to SOA? <ul><li>Forrester Research April 2005 </li></ul>End 2005 Now Who and what 21% 15% External Integration 74% 37% Internal Integration 40% 22% Small orgs 61% 28% Medium orgs 89% 70% Large orgs
    13. 13. More on who’s doing SOA <ul><li>Infoworld Research Report on SOA </li></ul><ul><li>Link is in the SOA e-lesson at ACSLearn </li></ul><ul><li>Check out ACSLearn e-lessons on </li></ul><ul><ul><li>Web Services </li></ul></ul><ul><ul><li>SOA </li></ul></ul><ul><ul><li>at </li></ul></ul>
    14. 14. An extract from the SOA e-lesson at ACSLearn <ul><li>“ SAP, IBM help drive SOA adoption” is a short article on these vendors involvement with SOA. At the same link you’ll find (as at April 2005) a link to an Infoworld survey on SOA adoption. You need to register to get this 25-slide presentation with February 2005 data on SOA adoption. The link is </li></ul><ul><li>There’s a longer (19-pages) but useful, CBDI Report “Service Oriented Architecture: An Introduction for Managers” by David Sprott available at </li></ul>
    15. 15. Some terms in SOA <ul><li>Composition </li></ul><ul><ul><ul><li>Making a composite of existing applications/services </li></ul></ul></ul><ul><li>Example: Airline/car rental/hotel reservation: Develop independently, then compose into a new service to co-ordinate all three. </li></ul><ul><li>Orchestration (internal) </li></ul><ul><ul><ul><li>Message exchange sequences </li></ul></ul></ul><ul><li>Choreography (external) </li></ul><ul><ul><ul><li>Executable processes </li></ul></ul></ul><ul><li>Many web services projects set up a service, but don’t take the next step of dynamically linking services into business processes </li></ul>
    16. 16. It’s a bit like music <ul><li>Just as there are only a set number of plotlines for literary artists to manipulate, there are only a set number of keys and rhythms for musicians to work with. Once the primary moves have been made, combination rather than origination becomes the mark of artistic genius: </li></ul><ul><li>Ray Charles: Gospel and R&B </li></ul><ul><li>Bob Dylan: Folk and ? </li></ul><ul><ul><ul><li>Source: The Australian, Imre’s column </li></ul></ul></ul>
    17. 17. SOA - It’s bigger than it seemed <ul><li>Processes </li></ul><ul><li>Services </li></ul><ul><li>Composite applications </li></ul><ul><li>Integration </li></ul><ul><li>Standards </li></ul><ul><li>Business agility </li></ul><ul><li>Leveraging existing technology assets </li></ul><ul><li>Architecture </li></ul><ul><li>Choreography </li></ul><ul><li>Orchestration </li></ul><ul><li>………… and it’s more complex than it may appear </li></ul>
    18. 18. SOA evolution <ul><li>Reuse </li></ul><ul><li>BPM </li></ul><ul><li>E-Commerce </li></ul><ul><li>ERP Backlash </li></ul><ul><li>Y2K </li></ul><ul><li>Compliance </li></ul><ul><li>Governance </li></ul><ul><li>Workflow </li></ul><ul><li>Internet </li></ul><ul><li>EDI </li></ul><ul><li>Cybercash </li></ul><ul><li>CORBA, DCE etc </li></ul><ul><li>EAI </li></ul><ul><li>XML </li></ul><ul><li>Web services </li></ul>
    19. 19. SOA in pictures <ul><li>The next few slides are from </li></ul><ul><li> </li></ul><ul><li>You can download these slides, but you need to register at the site. Reuse of these slides is encouraged by CBDI, provided their source is acknowledged. </li></ul><ul><li>We also look at some very good SOA pictures from Peter Campbell, an enterprise architect at ANZ Bank who was a panelist in Melbourne </li></ul><ul><li>Peter has also approved the use of his slides. </li></ul><ul><li>Reusability is a good thing but it requires collaboration. </li></ul><ul><li>Thanks to both sources. </li></ul>
    20. 20. Architectural Layers Business Process Layer Service Layer Application Layer Technology Layer Microsoft .NET Linux J2EE IBM CICS Finance HR ERP CRM Directory Lotus Notes Order Account Employee Customer
    21. 21. Provider and Consumer Architectures Component Architecture Component Architecture Consumer Provider Service Architecture Composite Application Architecture
    22. 22. SOA Layers Providing Resources and Implementations Service Enablement Implementation-Based and Utility Services Business Service Bus Composite Application Other Service Providers Composite Business Services Enterprise Service Bus Internal and External Resources Service Service Service Service Service Service Service Service
    23. 23. Enterprise Service Bus Middleware and/or Platform Resources Enterprise Service Bus Management Transport Security Orchestration Transformation EAI Server, XML Transformer, MOM, and other Transports WSM, Systems Management JCA, etc JMS, etc Security Server Orchestration Server WSDM Existing Application Resources ERP CRM Business Service Bus
    24. 24. SOA Maturity Model Technical Applications Application Integration Business Process Improvement Business Services Federated Business Collaborative services creating dynamic, collaborative business relationships Services directly implement business service capability Service as a process creates modular units of business process Service increases loose coupling and separation of concerns Data integration, client neutrality, shared internal services
    25. 25. Enterprise SOA Roadmap Early Learning Integration Reengineering Maturity Planning & Managing Architecture Infrastructure Process Resources Project Steering Managed and unmanaged organizational learning Short term ROI on primarily technical solutions Visioning, planning and communicating Common enterprise service bus capabilities Existing capabilities exposed as services Consistent use of services across the organization Cost reduction from (reuse) efficiency Increase in business agility from contract / trust based systems Provider / Consumer Organization Secure, transactional services environment Business processes reengineered as services Services federated across business ecosystems Monolithic systems reengineered as components Real time data currency and business intelligence Real time business services Service is basis for virtualized resource management Federated services management
    26. 26. The integration challenge for an enterprise <ul><li>IT systems evolve and become more complex like this over time </li></ul><ul><li>Every enterprise has a picture like this (sometimes it is not drawn!) </li></ul><ul><li>This includes an Enterprise Service Bus </li></ul><ul><li>SOA offers the potential to simplify integration using standard interfaces </li></ul>“ The Wiring Diagram”
    27. 27. SOA definition The policies, practices and frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer, which are abstracted away from the implementation using a single, standards based form of interface. Policies Practices Frameworks Application functionality Standards-based interface Consumers Source: CBDI Implementing SOA Enterprise Wide Service implementations
    28. 28. Services and business processes <ul><li>Services are linked to form business processes using process orchestration </li></ul><ul><li>Business services can utilise service orchestration </li></ul>Business Process Orchestration Business Services Technical Services Get customer details “ Open account for customer” Locate account type Add account to customer Locate customer record Check customer status Presentation – user interface Create Customer- Account record Lookup account type table Retrieve account details Business Process Coarse Grained Fine Grained Service Orchestration (Process Orchestration) Author : Peter Campbell, ANZ Banking Group Australia Author : Peter Campbell, ANZ Banking Group Australia
    29. 29. Process orchestration Service level Management Manual Process Process Orchestration Work item placed on work queue Process level Management Work item completed notification WSDL Workflow Automated processes <ul><li>Business processes are implemented by orchestrating services (e.g. using BPEL) </li></ul><ul><li>Process orchestration can include services triggering manual processes </li></ul><ul><li>A manual step in a process may make it slower and less robust than a fully automated process, but humans are really great computational units </li></ul><ul><li>Manual processes may impact quality of service (QoS) </li></ul>Service level management NOT available but status via workflow is <ul><li>Workflow handles management of manual processes </li></ul><ul><li>Process orchestration handles management of automated processes </li></ul>Business Service 1 Business Service 2 Business Service 3 Business Service 4
    30. 30. SOA standards stack example   Consumer Provider Single standard desirable Multiple standards acceptable There will be more . . <ul><li>NOTES: </li></ul><ul><li>WS-I basic profiles are important for ensuring interoperability and version levels of standards </li></ul><ul><li>SOA and services are independent of transport protocols </li></ul>Wire Description Discovery D W Di D D W W D D D D WS-Security – Liberty profile supports this (including SAML and XACML ) Security SOAP , WSIF Service invocation WSRP Presentation WS-BPEL Choreography XPATH, XQUERY, XBRL Data queries XSLT XML transformation SOAP , S/MIME, ebMS, WS-Reliability Messaging envelope XML , EDI, IIOP, BER encoding Document syntax XML Schema , RelaxNG, DTD, ASN.1, RDF Schema, IFX, LIXI Schema of the syntax WSDL Service description UML Knowledge definition UBL Generic vocabulary Standard Layer
    31. 31. SOA and Web services <ul><li>SOA can be implemented without Web services, and Web services can be used for non-SOA (e.g. RPC) interactions. However, Web services delivers key standards for implementing SOA. </li></ul><ul><li>The WS-* family scales to meet integration challenges intra-enterprise (enterprise application integration [EAI] ) and inter-enterprise (business to business [B2B] ). </li></ul><ul><li>XML is an ideal candidate for loosely coupled inter-application data sharing. XML is not self-describing, but XML Schema can be be used to constrain message layout and content. </li></ul><ul><li>RPC interactions </li></ul><ul><li>Binary XML </li></ul><ul><li>Services architecture </li></ul><ul><li>Service contract </li></ul><ul><li>Message based </li></ul><ul><li>Service directory </li></ul><ul><li>Protocol independent </li></ul><ul><li>Coarse grained & document centric </li></ul><ul><li>Web services specs </li></ul><ul><li>WSDL </li></ul><ul><li>SOAP & XML </li></ul><ul><li>UDDI </li></ul><ul><li>HTTP </li></ul><ul><li>Doc literal binding </li></ul><ul><li>Process orchestration (BPEL) </li></ul>Web Services is the stack of standard web technologies required at both consumer and provider ends to implement the pipe for shipping XML messages between them. You don't have SOA until you build/buy services and compose them to implement business functionality. Web services “ The plumbing” SOA “ The architecture”
    32. 32. Getting ready for SOA “ Top down” and “bottom up” considerations need to be balanced. Technical Ownership Business Ownership Funding SOA Design and Development Skills Repository Proof of Concepts Simple Web Services Select SOA tools Technology Enablers Governance Business Architecture <ul><li>Principles </li></ul><ul><li>Patterns </li></ul><ul><li>Architecture </li></ul><ul><li>Skills </li></ul>Top down Bottom up <ul><li>Measurement </li></ul><ul><li>Management </li></ul><ul><li>Rewards </li></ul>
    33. 33. Example: Simplification and reducing testing Current transaction management Consumers Consumers Changes Changes End-to-end testing required to cover all the interdependencies Testing is only required against the standard interface Simplified transaction management Current State Proposed Legacy and Shared Systems Changes Many tightly coupled interfaces Standard interfaces Legacy and Shared Systems Development to testing ratio 1: 9 Development to testing ratio 1:3 (best practice target) Reduced change dependencies yield reduction in testing in this specific example NOTE: This example only applies to a subset of existing transactions
    34. 34. IS SOA New? <ul><li>Not really, there’s new standards that make it easier to implement </li></ul><ul><li>The services in SOA are business services, e.g. update a loan but not update a record </li></ul><ul><li>Linking services creates business processes, business process engines and languages make this easier </li></ul><ul><li>Business partners can use each others services </li></ul><ul><li>Favours flexibility over efficiency </li></ul><ul><li>Services are not tied to user interfaces, interfaces invoke services. </li></ul><ul><li>Gives new life to legacy systems </li></ul><ul><ul><li>Check out John Reynolds Blog (ACSLearn e-lesson) </li></ul></ul>
    35. 35. The assignment <ul><li>Answer the questions in the integration survey in Section 3.1 for your case organisation; (5%) </li></ul><ul><li>Sample questions </li></ul><ul><ul><li>In the past 12 months how often asked to integrate information held in disparate systems? </li></ul></ul><ul><ul><li>What % of these requests could be met in timeframe of the business? </li></ul></ul>
    36. 36. More on the assignment <ul><li>Explain the current IT architecture; (5%) </li></ul><ul><li>Identify and justify the maturity level of your organisation’s enterprise architecture; (5%) </li></ul><ul><li>Identify any business challenges the current integration architecture and integration approaches create; (10%) </li></ul>
    37. 37. More of the assignment <ul><li>Examine how a move towards a service-oriented architecture would address these challenges; (15%) </li></ul><ul><li>Identify any technical and/or organisational challenges associated with introducing an SOA. (15%) </li></ul><ul><li>Identify the core services that your organisation could offer as services in a SOA.(15%) </li></ul>
    38. 38. But wait…..there’s more <ul><li>Explain which, if any, of the international IT guidance standards are in use in your organisation. (5%) </li></ul><ul><li>Make recommendations as to which of the standards are relevant and suitable for the organisation. (5%) </li></ul><ul><li>Prepare a 10-minute presentation suitable for senior business executives in your organisation, the title of which is “Do we need service-oriented architecture.” (20%) </li></ul>
    39. 39. The Reality <ul><li>Panel </li></ul><ul><li>Short break for 2 minutes. </li></ul><ul><li>Talk among yourselves about the questions you want the panel to answer. </li></ul>