Presentation is loading. Please wait.

Presentation is loading. Please wait.

Sponsored by the U.S. Department of Defense © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 1 Pittsburgh, PA 15213-3890.

Similar presentations


Presentation on theme: "Sponsored by the U.S. Department of Defense © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 1 Pittsburgh, PA 15213-3890."— Presentation transcript:

1 Sponsored by the U.S. Department of Defense © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 1 Pittsburgh, PA Migration of Legacy Assets to SOA Environments Dennis Smith and Grace Lewis Software Engineering Institute

2 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 2 Our Goal Today Present and discuss Basic concepts related to SOA Challenges of implementing SOA-based systems Effects of SOA characteristics on migration of legacy assets to services Technique for determining feasibility and effort required to migrate legacy assets as services for a specific SOA environment Goal

3 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 3 Agenda Introduction to SOA Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments SMART (Service Migration and Reuse Technique) Conclusions and Next Steps Agenda

4 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 4 Agenda Introduction to SOA The 50,000 Foot View -Basic Concepts -Common Misconceptions The 5,000 Foot View The 1,000 Foot View Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments SMART (Service Migration and Reuse Technique) Conclusions and Next Steps SOA: 50,000 Foot View

5 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 5 What is SOA? Service-oriented architecture is a way of designing systems that enables Cost-efficiency Agility Adaptability Leverage of legacy investments SOA: The 50,000 Foot View—Basic Concepts

6 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 6 Services Services are reusable components that represent business tasks. Customer lookup Account lookup Credit card validation Credit check Hotel reservation Interest calculation Services can be Globally distributed across organizations Reconfigured into new business processes SOA: The 50,000 Foot View—Basic Concepts

7 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 7 Services and Cost-Efficiency Order Processing Application Customer Lookup - 1 Invoicing Application Customer Lookup - 2 CRM Application Customer Lookup - 3 Customer Lookup Service A service with equivalent functionality can be implemented and used by all three applications SOA: The 50,000 Foot View—Basic Concepts

8 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 8 Services and Agility Order Processing Application Customer Lookup Service Credit Check Service Item Lookup Service Inventory Check Service Course Management Application Room Availability Service The new application can easily use available services. New services can be used by other applications as well. SOA: The 50,000 Foot View—Basic Concepts

9 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 9 Services and Adaptability Order Processing Application Customer Lookup Service Credit Check Service Item Lookup Service Inventory Check Service SOA Infrastructure The SOA Infrastructure provides a standard communication mechanism between applications and services. Changes in services have potentially no impact on existing applications that use them. SOA: The 50,000 Foot View—Basic Concepts

10 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 10 Services and Legacy Leverage Order Processing Application Customer Lookup Service Credit Check Service Item Lookup Service Inventory Check Service SOA Infrastructure Customer Management System The applications access the services in a standard way. It is the service’s task to invoke the legacy system. Legacy platform diversity and complexity is transparent to the application. SOA: The 50,000 Foot View—Basic Concepts Manufacturing System

11 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 11 Components of an SOA-Based System Application X Service A SOA Infrastructure Enterprise Information System Application Y Application Z Interne t External System Service B Service C Service D Internal Users DiscoverySecurity Development Tools Legacy or New Code SOA: The 50,000 Foot View—Basic Concepts

12 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 12 In Summary … SOA is an approach to software development where Services provide reusable functionality with well-defined interfaces. An SOA infrastructure enables discovery, composition and invocation of services. Applications are built using functionality from available services. If managed well, SOA adoption can lead to Cost-efficiency Agility Adaptability Leverage of legacy investments The hard part is the “if managed well”. SOA: The 50,000 Foot View—Basic Concepts

13 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 13 Agenda Introduction to SOA The 50,000 Foot View -Basic Concepts -Common Misconceptions The 5,000 Foot View The 1,000 Foot View Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments SMART (Service Migration and Reuse Technique) Conclusions and Next Steps SOA: The 50,000 Foot View—Common Misconceptions

14 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 14 An SOA Provides The Complete Architecture For A System SOA is an architectural pattern/style/paradigm and not the architecture of the system itself. An architectural pattern provides guidance that embodies best practices. The concrete elements and their interactions are the architecture of the system. Any number of systems can be developed based on an architectural pattern. An architecture based on SOA inherits both the good and the bad. Corollary: SOA cannot be bought off-the shelf. System qualities have to be built into the architecture of the system. Decisions have to be made—service design and implementation, technologies, tradeoffs. SOA: The 50,000 Foot View—Common Misconceptions

15 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 15 Legacy Systems Can Be Easily Integrated Into An SOA Environment Upfront hands-on analysis on the technical feasibility and return on investment must be performed to avoid last minute surprises. Is it technically feasible to create a service from the legacy system or part of the system? How much would it cost to expose the legacy system as services? Is this cost plus the cost of maintaining the legacy system more than the cost of replacing it with a new one? What changes will have to be done to the legacy system? How much will these changes affect current users and other production systems? SOA: The 50,000 Foot View—Common Misconceptions

16 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 16 Using XML and WSDL Guarantees Interoperability Among Web Services Provided by Multiple Organizations Web Services enable syntactic interoperability XML Schema defines structure and data types WSDL defines the interfaces: operations, parameters and return values Available information, technologies and tool support Web Services do not guarantee semantic interoperability XML and WSDL do not define the meaning of data WSDL does not define what a service does Active research area—unresolved issues Interoperability needs agreement on both syntax and semantics SOA: The 50,000 Foot View—Common Misconceptions

17 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 17 SOA Is All About Technology SOA not only means a shift in technology but also changes in the organizational governance model. Service definition Service repositories Ownership -Common services? Data? Evolution Conflict resolution Deployment mechanisms Monitoring mechanisms Enterprise-wide policies Service-level agreements SOA: The 50,000 Foot View—Common Misconceptions

18 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 18 It Is Easy To Develop Applications Based on Services It is relatively easy to build services to work with a particular infrastructure … but designing a “good” service might not be that easy. From a implementation standpoint -Ease depends on tool availability for SOA infrastructure -Most difficult part is composition—data mismatches From a design standpoint -Not many best practices for designing services -Have to anticipate potential users and usage patterns -What is the right Quality of Service? Can you guarantee it? -“If you build it they will come” – Can you afford this? SOA: The 50,000 Foot View—Common Misconceptions

19 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 19 It is Easy to Compose Services Dynamically at Runtime Current technologies have not advanced to the point that this is possible in production environments. Requires the use of a common ontology by service providers and client applications within a domain Requires the construction of extremely intelligent applications that Construct the right queries for the discovery of services Compose services when there is not a single service that can process the request Provide the right data to invoke a service that was discovered at runtime SOA: The 50,000 Foot View—Common Misconceptions

20 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 20 In Summary … Our intent is not to discourage, but to caution. An SOA approach may be the best way to achieve common goals of interoperability, agility, and reuse. But … Most of the mentioned issues are active areas of research. Some solutions will require time to mature. Also keep in mind … Not everything in an SOA-based system has to be a service -It might not make sense for your whole system Most case studies will show that the key is governance -Which has very little to do with technology SOA: The 50,000 Foot View—Common Misconceptions

21 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 21 Agenda Introduction to SOA The 50,000 Foot View The 5,000 Foot View -Web Services The 1,000 Foot View Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments SMART (Service Migration and Reuse Technique) Conclusions and Next Steps SOA: The 5,000 Foot View

22 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 22 Web Services Web services is one mechanism for implementing an SOA- based system. Service interfaces are described using Web Services Description Language (WSDL) Data is transmitted using SOAP over HTTP UDDI is optionally used as the directory service Because it is the most common mechanism, it is often equated to SOA. SOA: The 5,000 Foot View—Web Services

23 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 23 Web Service Protocol Stack The highlighted standards are the most commonly used Most Web Service standards are emerging and even competing Security, QoS, Transactions, and Management have to be addressed in all layers SOA: The 5,000 Foot View—Web Services

24 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 24 Web Services At Design Time Alice obtains the WSDL corresponding to Bob’s web service Alice runs the WSDL document through tools that generate all the necessary message construction code (e.g. WSDL2Java) Bob exposes functionality in a system as a service (or creates a specific service) and places a WSDL document in an “accessible place” Alice adds code to her application that executes the message construction code to connect to Bob’s web service and any additional code that uses the response obtained from Bob’s web service SOA: The 5,000 Foot View—Web Services

25 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 25 Web Services At Run Time 1.User executes Alice’s application 3.When Bob’s HTTP server sees a SOAP message it sends it to the SOAP engine 2.Application builds a SOAP message and sends it to Bob’s service via HTTP 4.SOAP engine parses the message and constructs the call to Bob’s system 5.Bob’s system executes the invoked operation 6.Bob’s system returns operation results HTTP Request Call Return HTTP Response 7.SOAP engine builds response message and returns it via HTTP HTTP ServerBob’s SystemUser at Alice’s Application 8.Alice’s application interprets response and displays results to the user. SOA: The 5,000 Foot View—Web Services

26 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 26 Static vs. Dynamic With today’s technology, discovery and composition of services are done at design time—Static Developer discovers services and obtains addresses Developer writes code to invoke the services located at these addresses There is a great amount of research to enable discovery and composition at runtime—Dynamic Application discovers services and obtains addresses Application contains code to invoke the discovered services and “knows” what information to provide There are a lot of “In-Between” techniques Application discovers services but requires user intervention to select services and provide the required information Portals are configured such that “portlets” correspond to services SOA: The 5,000 Foot View—Web Services

27 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 27 In Summary … Web Services are the most currently used approach to SOA implementation. Basic infrastructure standards are fairly stable More higher level standards are emerging Web Services are not the only approach to SOA implementation. SOA: The 5,000 Foot View—Web Services

28 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 28 Agenda Introduction to SOA The 50,000 Foot View The 5,000 Foot View The 1,000 Foot View Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments SMART (Service Migration and Reuse Technique) Conclusions and Next Steps SOA: The 1,000 Foot View

29 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 29 Components of an SOA-Based Systems 1.Services 2.Applications 3.SOA Infrastructure SOA: The 1,000 Foot View

30 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 30 Our Scenario: SOA-Based System Components Order Management System Financial System Organization 1 Organization 2 Credit Card Validation System SOA Infrastructure Order Processing Application CRM Application Shipping System FedEx Shipping System UPS Shipping System DHL Order Placement Application Customer Organization Interne t SOA: The 1,000 Foot View

31 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 31 Distribution of SOA-Based System Development SOA: The 1,000 Foot View Organizational ESB Incorporation of Map Data “Just-In-Time” Inventory Management Software as a Service Single Organization Multiple Organizations Net-Centric Operations On the left side of the spectrum all three types of components are developed within the same organization. On the right side of the spectrum each type of component is developed by a different organization. There are many possibilities in between. As you move to the right, the challenges are greater.

32 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 32 Application Developers 1 Focus on the discovery, composition and invocation of services, either statically at design time or dynamically at run time SOA: The 1,000 Foot View

33 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 33 Application Developers 2 1. Identify appropriate services (both internal and external) that can be reused Order Management System Financial System Organization 1 Organization 2 Credit Card Validation System SOA Infrastructure Order Processing Application CRM Application Shipping System FedEx Shipping System UPS Shipping System DHL Order Placement Application Customer Organization Interne t … as well as if it needs to become a service provider itself 2. Understand the interfaces in terms of the functionality and QoS provided by them Application Developer needs to create a new application using the SOA approach SOA: The 1,000 Foot View 3. Create the new system using as many existing services as possible 4. The application needs to be architected in such a way that it can easily accommodate changes in services interfaces …

34 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 34 Tasks for Application Developers Understand the SOA infrastructure Discover appropriate services to be incorporated into applications Retrieve service description documentation Invoke the identified services in applications Data conversions Error handling Availability handling Test the services for correctness in the context of the application being developed SOA: The 1,000 Foot View

35 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 35 Service Developers Focus on the description and granularity of services so that applications can easily locate and use them with acceptable Quality of Service (QoS) SOA: The 1,000 Foot View

36 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 36 Service Developers 1. Identify what existing business functionality can be exposed/reused as services Order Management System Financial System Organization 1 Organization 2 Credit Card Validation System SOA Infrastructure Order Processing Application CRM Application Shipping System FedEx Shipping System UPS Shipping System DHL Interne t 4. Design, create and publish services to internal and external organizations 3. Anticipate requirements for future consumer systems and architect services in a scalable fashion 2. Analyze service interface, functionality and QoS requirements for new consumer systems SOA: The 1,000 Foot View

37 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 37 Tasks for Service Developers Understand requirements of potential service users Understand SOA infrastructure Develop code that receives the service request, translates it into calls into new or existing systems, and produces a response Describe and publish the service Develop service initialization code and operational procedures Service-Level Agreements (SLAs) are a topic of current interest among service providers. SOA: The 1,000 Foot View

38 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 38 Infrastructure Developers Focus on providing a stable infrastructure Standards Common services Development tools NOTE: The Enterprise Service Bus (ESB) is an example of an infrastructure designed to support the SOA paradigm. SOA: The 1,000 Foot View

39 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 39 Infrastructure Developers 2 Order Management System Financial System Organization 1 Organization 2 Credit Card Validation System SOA Infrastructure Order Processing Application CRM Application Shipping System FedEx Shipping System UPS Shipping System DHL Interne t Infrastructure developers have to design, create and maintain these common services for both internal and external use (if required) Discovery Security Development Tools Service Registry There are common services that are used by all applications SOA: The 1,000 Foot View

40 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 40 Tasks for Infrastructure Developers Selection of standards to implement as part of the infrastructure Development of a set of common infrastructure services for discovery, communication, security, etc. Identification and development of binding mechanisms to satisfy the largest set of potential service users Provision of tools for application and service developers Documentation and support for the infrastructure SOA: The 1,000 Foot View

41 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 41 The Potential Problem If the three types of components are developed within the same organization, the challenges are less. Simpler communication between developers (or might even be the same developers) However, it is becoming increasingly common for these three types of components to be developed independently by separate organizations. Decisions made locally by any one of these development groups can have an effect on the other groups. SOA: The 1,000 Foot View

42 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 42 Sample Consequences of Decisions: Service Granularity 1 The granularity of service interfaces can affect the end-to- end performance of an SoS because services are executed across a network as an exchange of a service request and a service response. If service interfaces are too coarse-grained, clients will receive more data than they need in their response message. If service interfaces are too fine-grained, clients will have to make multiple trips to the service to get all the data they need. SOA: The 1,000 Foot View

43 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 43 Sample Consequences of Decisions: Service Granularity 2 Order Management System [Basic Info, Order History, Pending Orders] getCustomerInfo( CustomerId ) The Order Management System can expose the business functionality of getting all the customer information in one call OrderHistory getOrderHistory( CustomerId ) CustInfo getCustBasicInfo( CustomerId ) Order[] getPendingOrders( CustomerId ) Or the service can be more granular and provide three different operations for each type of information SOA: The 1,000 Foot View

44 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 44 Sample Consequences of Decisions: Requirements 1 If service developers do not understand functionality and QoS needs of potential users of services, they might end up developing and deploying services that are never used SOA: The 1,000 Foot View

45 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 45 In Summary … SOA-based systems are about more than just technology. SOA-based systems development requires 1.Strategic approach to SOA implementation Alignment with business goals 2.SOA governance Policies, coordination and guidance for SOA infrastructure providers, service providers, and application developers 3.Realistic technology evaluation Context-based technology evaluations 4.Change of mindset Different development and implementation approach SOA: The 1,000 Foot View

46 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 46 Agenda Introduction to SOA Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments SMART (Service Migration and Reuse Technique) Conclusions and Next Steps

47 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 47 Pillars of SOA-Based Systems Development Strategic Alignment SOA Design Principles SOA-Based Systems Development Technology Evaluation SOA Governance Change of Mindset

48 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 48 Strategic Alignment SOA Design Principles SOA-Based Systems Development Technology Evaluation SOA Governance Change of Mindset Pillars: Strategic Alignment

49 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 49 Alignment with Business Goals Any successful SOA strategy has to be aligned with business goals. Examples Reduce time to market for applications Increase information available to customers Integrate business partners Decrease development cost by increasing reuse Reduce maintenance costs Improve customer service Improve internal processes Pillars: Strategic Alignment

50 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 50 Service Conception 1. Business processes to support business goals are identified. 2. Candidate services are identified. Top-Down -Shared steps between business processes are identified as service candidates. Bottom-Up -Legacy system inventory is performed. -Systems with functionality to support business processes are identified as migration candidates. 3. Services are selected based on relationship to business goals. Pillars: Strategic Alignment

51 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 51 SOA Governance Strategic Alignment SOA Design Principles SOA-Based Systems Development Technology Evaluation SOA Governance Change of Mindset Pillars: SOA Governance

52 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 52 Lack of Governance Inhibits SOA Adoption An InfoWorld 2006 SOA Trend Survey indicates that Lack of Governance is the main inhibitor for SOA adoption (48%) Greater than other inhibitors that would seem more obvious Unresolved security issues (40%) Performance and reliability (39%) Incomplete and immature standards (38%) Pillars: SOA Governance

53 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 53 SOA Governance Policies and procedures Roles and responsibilities Design-time governance Run-time governance Pillars: SOA Governance Source: Integration and SOA: Concepts, Technologies and Best Practices. Beth Gold-Bernstein & Gary So.

54 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 54 Policies and Procedures Service providers Service conception Service modeling Service development Service deployment Infrastructure providers Infrastructure versioning Upgrades Application developers Service composition Application testing Pillars: SOA Governance

55 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 55 Roles and Responsibilities Roles SOA Governance Manager Close work with -Business process managers and analysts -Project managers -Infrastructure managers -Service managers Responsibilities Creation Approval Implementation Enforcement Pillars: SOA Governance

56 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 56 Challenges of SOA Governance Seems counterintuitive If SOA is all about loose coupling and flexibility, why all this central control? Multiple organizations How to create governance for service providers, infrastructure providers, and application developers? What if policies conflict? Dealing with exceptions How to record and maintain sometimes necessary exceptions? Enforcing compliance How to make sure that policies and procedures are being followed at design time and runtime? What are the incentives for compliance? Pillars: SOA Governance

57 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 57 Technology Evaluation Strategic Alignment SOA Design Principles SOA-Based Systems Development Technology Evaluation SOA Governance Change of Mindset Pillars: Technology Evaluation

58 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 58 Match of Technologies to the Problem Domain Realistic understanding on what technologies can do in the specific problem domain. How to understand and keep up with the “alphabet soup”? XML, SOAP, WSDL, UDDI, WS-Security? How to determine which standards and technologies to implement in specific situations? How to build systems that are resilient to changes in standards and commercial products that implement them? Pillars: Technology Evaluation

59 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 59 Technology Checks TechChecks are prototypes, situated in a specific context, with the goal of providing a “technology sanity check”. Model problems are ruthlessly efficient—no glitz; just answer the question. The model problem approach involves 1.Formulating hypotheses about the technology 2.Examining these hypotheses against very specific criteria through experimentation Pillars: Technology Evaluation

60 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 60 TechCheck Example: Context Organization migrating from a federated suite of legacy applications and data stores to a solution based on Web services. Establish feasibility of Adapting current systems Maintaining (or improving) current response time Allowing image transfer Providing single sign-on. Pillars: Technology Evaluation

61 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 61 TechCheck Example: Hypotheses and Criteria Pillars: Technology Evaluation HypothesisCriteria 75% or more of existing applications can be adapted to Web services. 1.There are SOAP libraries that can be easily linked into 75% of existing applications. 2.If not, there are clear mappings between native data types and XML Schema data types that will allow for manual serialization and deserialization of SOAP messages. Response time will not be degraded due to the use of Web services. Response times using Web services will be within the same order of magnitude from current response times for representative applications. Images can be transmitted as part of SOAP messages. An image can be requested using Web services and viewed on a client application. It is possible to have single sign-on using Web services. A user is able to login once and obtain information from three different Web services residing on three different machines.

62 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 62 Change of Mindset Strategic Alignment SOA Design Principles SOA-Based Systems Development Technology Evaluation SOA Governance Change of Mindset Pillars: Change of Mindset

63 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 63 SOA-Based Systems Require a Different Development Approach Traditional System Development Tight coupling between system components Shared semantics at design time Known set of users and usage patterns System components all within the same organization SOA-Based System Development Loose coupling between applications and services Semantics ideally enable dynamic discovery and execution of services Potentially unknown service users and usage patterns Multiple organizations providing system components Pillars: Change of Mindset

64 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 64 Less Control Requires giving up control—not easy Anticipate objections and understand validity Security Performance Control Greatest challenges come from Single organization may not own the system Services used in unknown ways by (potentially) unknown users Education and training on new mindset is needed Pillars: Change of Mindset

65 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 65 Agenda Introduction to SOA Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments Reuse Issues SOA Issues SMART (Service Migration and Reuse Technique) Conclusions and Next Steps

66 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 66 Reuse in the SOA Context Reuse at a higher level Reuse of business functionality Encapsulation of technical details Reuse across organizations Organizations can “sell” their core business expertise as services Functionality can be acquired as opposed to developed from scratch—potential savings Option for leveraging legacy system investment In most cases, legacy components can be reused by exposing them as services, independent of vendor, platform and technology Migration Issues: Reuse

67 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 67 Reuse Issues 1 Reuse at the service level is more complex than reuse at module or component level Designing reusable services requires a different approach, skill set, and mindset Bigger stakeholder community because services are typically reused at organization and sub-organization level Migration Issues: Reuse

68 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 68 Reuse Issues 2 It may not always be possible to reuse business functionality of legacy applications by exposing them as services Technical constraints due to the nature of the legacy application -A batch system needs to be exposed as a service for an interactive online web application Immature technology or lack of technology for a particular legacy environment Cost of exposing a legacy business application as services may be higher than actually replacing the system with a new SOA-based system Migration Issues: Reuse

69 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 69 Addressing Reuse Issues Identify relevant and non-relevant legacy assets Not all legacy assets can be meaningfully reused as services—both from a strategic and technical perspective Make decisions based on “hands-on”, contextual analysis System-specific analysis is important because every system is unique Previous analysis and results can be used a guidelines Estimate cost, risk and confidence of estimates of changes required to each legacy component Migration Issues: Reuse

70 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 70 Agenda Introduction to SOA Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments Reuse Issues SOA Issues SMART (Service Migration and Reuse Technique) Conclusions and Next Steps

71 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 71 Migration to SOA Environments: A Complex Engineering Task The characteristics of SOA enable the exposure of legacy system functionality as services Presumably without making significant changes to the legacy systems Constructing services from existing systems in order to obtain the benefits of SOA is neither easy nor automatic Such a migration can represent a complex engineering task Particularly when the services are expected to execute within a tightly constrained environment Migration Issues: SOA Characteristics

72 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 72 Legacy System Characteristics There are aspects of the legacy system that could make the effort challenging Poor separation of concerns -User interface code tightly coupled with business function code Tool availability -XML and SOAP libraries are not available for all legacy platforms Architectural mismatch -The asynchronous call to the service might be in conflict with legacy system synchronous behavior Operational mismatch -The legacy system is batch-oriented, the service user expects an immediate response Dependencies on commercial products -Licensing issues? Migration Issues: SOA Characteristics

73 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 73 Bottom Line There are issues to take into consideration that go beyond adding a service interface to an existing system. SMART is an initial approach to the identification and analysis of issues in migration to services. Migration Issues: SOA Characteristics

74 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 74 Agenda Introduction to SOA Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments SMART (Service Migration and Reuse Technique) Conclusions and Next Steps

75 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 75 SMART: The Service-Oriented Migration and Reuse Technique Assists organizations in making initial decisions when analyzing legacy components for reuse as services Focuses on the reuse of legacy components as services in an SOA Outcome is a migration strategy for the organization SMART: Introduction

76 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 76 Three Elements of SMART 1.Process that Gathers information about -Goals of migration effort -Candidate services -Legacy components -Target SOA Analyzes gap between legacy and target state 2.Service Migration Interview Guide (SMIG) Guides discussions in initial SMART activities 3.Templates for Output Products – examples: Component table Service table Migration strategies SMART: Elements

77 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 77 SMART Process Activities Establish Migration Context Describe Existing Capability Describe Target SOA State Analyze the Gap Develop Migration Strategy SMART Elements: Process Activities

78 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 78 Sample SMIG Content Migration Context Goals and Expectations Critical Business Processes Potential Service Users Legacy System Developers, End Users and Owners Existing Capabilities Legacy System Characteristics System Architecture Code Characteristics Interfaces with Other Systems Target SOA State Service Requirements Target SOA Data Models Legacy System Adaptation Service-Oriented Changes Quality of Service Support Service Setup Problem Reporting and Feedback Updates and Upgrades User Communities SMART Elements: SMIG

79 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 79 SMART Artifacts Establish Migration Context Describe Existing Capability Describe the Target SOA State Analyze the Gap Develop Migration Strategy Stakeholder ListCreateUpdate Characteristics List CreateUpdate Migration Issues List CreateUpdate Critical Business Processes CreateUpdate Service TableCreateUpdate Component TableCreateUpdate Component Service Options Table CreateUpdate Migration Alternatives Table Create Service Migration Strategy Create Final PresentationCreate SMART Artifacts

80 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 80 Case Study: Clinical Lab System SMART Case Study: Context Patient Clinic Doctor’s visit Hospital Admission Clinical Lab Order Test Billing information Insurance Aggregate data for research Clinical Research Center/ University Results Patient Portal Patient Data Patient Data Results

81 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 81 Case Study: Clinical Lab System Context Diagram Lab information shared between many systems Need to move to a SOA environment to increase reusability of common lab tasks Key questions: 1.Which services should be created from legacy assets? 2.In what order? 3.Should some legacy components be replaced with new components? Lab System Inpatient System Outpatient System Research System Patient Information Online Insurance SMART Case Study: Context SMART Engagement Scope

82 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 82 Establish Migration Context Understand the business and technical context for migration Identify stakeholders Select candidate services for migration SMART Activities: Establish Migration Context

83 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 83 Case Study: Understand Business Drivers for Legacy Migration Improve patient care by Standardizing the access to lab information using services Providing access to lab information from any clinical system in real time (current access is mostly batch- oriented) Making lab information accessible to patients via the Internet using a patient portal Reduce IT costs by Creating common and reusable services Reducing the multiple redundant interaction points (interfaces) Lowering maintenance and upgrade costs by using an SOA environment SMART Case Study: Understand Business Context

84 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 84 Case Study: Identify Stakeholders Lab System Inpatient System Outpatient System Research System Patient Information Online Insurance Legacy system: Clinical Lab Legacy system developers, service designers, business manager, project manager Outpatient physicians, architects, Service designer, IT/Infrastructure staff Inpatient doctors, software architects, service designers, IT/Infrastructure staff Patients, Portal architect, Developers Researchers, IT infrastructure developers Insurance policy makers, architect Existing system: Medical School Existing system: Clinics Existing system: Hospitals New system: Patients on Internet Existing system: Insurance Companies SMART Case Study: Identify Stakeholders

85 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 85 Establish Migration Context: SMIG Examples Discussion Topic Related Questions RationaleWhy is the migration to an SOA environment being considered? ExpectationsWhat are the expectations from the migration effort? Potential Service Users Have users or systems that will use the services been identified? How were their service requirements identified? Legacy System Stakeholders Who owns the legacy system? Who developed the legacy system? Business Goals and Processes What are the main business goals? What are the main business processes that support these goals? What are common steps/tasks between these business processes? SMART Activities: Establish Migration Context

86 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 86 Establish Migration Context: Tasks Create Stakeholder List Create Characteristics List Create Migration Issues List Update at any time! Stakeholders Contact Information Information to be elicited from each Identify component characteristics to be gathered Some are predefined Others vary with context Provides data for analysis process Identify issues as they become evident General issues affect the overall migration effort Component- or service-specific issues Create Service Table Identify candidate services and the business processes they support Identify potential information sources Architects Service users Domain groups Communities of Interest (COIs) SMART Activities: Establish Migration Context

87 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 87 Case Study: Service Table ServiceDescriptionService TypeBusiness Process Supported Get Test Results Details Obtains detailed test results either for one patient or for all the patients for which tests were completed on a day for a particular location. Business Analysis and mining for trends Review and report of results Archival and retrieval of test results Data Transfer Service Wraps and transfers all data payload to external systems. Infrastructure Business services internal to the Lab system External applications or services that need to provide bulk data back to the Lab system Service Potential Service Users ………… Get Test Results Details Hospital, Clinic and Patient applications Data Transfer Service Internal services and external applications and services SMART Case Study: Service Table

88 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 88 Describe Existing Capability: Tasks Update Characteristics List Create Component Table Update Migration Issues List Identify components for potential migration Gather characteristic data for each component Characteristics become columns of the component table Indicate data to be gathered about each component Issues will appear as data is gathered SMART Activities: Describe Existing Capability

89 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 89 Case Study: Implementation Characteristics Written in C++ and Java Some components run on Windows operating system and some on Unix OS ~2500 C++ classes and ~1500 Java class 800,000 lines of code Dependencies on several commercial products: Oracle Database Weblogic Application Server SMART Case Study: Legacy System Characteristics

90 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 90 Case Study: Updated Migration Issues Description: All service consumers do not plan to move to the XML compliant version (v3) of HL7 Description: Some legacy components are designed only for batch operations ….. Description: Some legacy components have direct calls to UI embedded in the core business logic of the code Issue Type: Technical Related Component: Lab Results Reporting, Order Processing Complexity: Medium Description: Different data filtering policies are applied to the same data depending upon on the interacting external system Issue Type: Business, Policy Related Component: Results Retrieval Complexity: Low SMART Case Study: Migration Issues New

91 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 91 Describe Target SOA State: Tasks Update Characteristic s List Create SOA Descriptio n Update Service and Component Tables Update Migration Issues List SOA Description will most likely provide additional characteristics to be gathered about services and components SMART Activities: Describe Target SOA State

92 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 92 Case Study: Updated Component Table Component Programming Language Age (years) Size (SLOC) Complexity Level of Documentation Version LabTestCatalog Java612,000MediumHigh 5.6 OrderProcessor C++88,000Very HighMedium 8.2 Component Last Release Date Max. Depth of Inheritance Coupling (# of classes) CohesionCOTS Dependency LabTestCatalog 02/10/ Medium Oracle database, Weblogic Application Server, HL7 v2.3 OrderProcessor 06/01/ Fair Customer Interface Engine, Some 3 rd party libraries Component Direct Calls to UIHard coded Policies and Rules Security Requirement Level Updated Detailed Design Document Available? LabTestCatalog YesNoMediumNo OrderProcessor Yes HighYes SMART Case Study: Component Table

93 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 93 Case Study: Target SOA State Business Services Reusable business services that are created by reusing the existing legacy code base Policy Manager Centralizes the configuration, deployment, change management and storage of policies Infrastructure Data Transfer Service Used by all the business services to transfer and receive data from external systems Infrastructure Security Service Provides secure transmission of a confidential data Provides authorization and authentication services from external interacting systems Infrastructure Data Format Service Formats messages according to HL7 v2.x or HL7 v3 as needed by business services and external applications SMART Case Study: Target SOA Characteristics

94 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 94 Case Study: Target SOA Constraints Services shall support different versions of the HL7 standard Patient Portal will use the new XML complaint version (v3) of HL7 Some other systems (Outpatient, Inpatient) plan to move to HL7 v3 in near term while others don’t have any plans Services shall take into account the different policy requirements for the same data Research data should be completely anonymous (without any Personally Identifiable Information – PII) Inpatient/outpatient data should be completely identifiable for each patient SMART Case Study: Target SOA Characteristics

95 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 95 Case Study: High-Level Target SOA Research Database Test Results Service Security Service Order Lab Test Service Get Patient Informati on Enterprise Service Bus (ESB) Results and Reporting Order Processing Component Inpatient System Outpatient System Insurance Company System Data Transfer Service SMART Case Study: Target SOA Characteristics Data Format Service Patient Portal Policy Manager

96 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 96 Analyze the Gap: Tasks Create Component Service Options Table Identify Additiona l Data Needed Gather Additional Data Analyze Component/Servic e Options Map components to services Need not be one-to-one Alternate approaches may be possible Incomplete or untrustworthy data? Architectural analysis Architectural reconstruction Code analysis Update all tables! Estimate cost/effort Determine risk SMART Activities: Analyze the Gap

97 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 97 Case Study: Analyses Performed Three types of analysis performed Informal evaluation of code quality -No consistent coding standards in force -Parts of the code had little cohesion -Awkward and non-standard class/modules organization Architectural reconstruction to gain a better understanding of code dependencies when the SMART team found discrepancies Effort and cost estimation of changes necessary to migrate legacy components SMART Case Study: Gap Analysis

98 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 98 Case Study: Key Findings Insufficient architectural and other high-level documentation to accurately determine class dependencies Potential for underestimation of the amount of code used by the potential services No details on code module dependencies No consistent programming standard Automated code analysis is not easy Violation of Model-View-Controller architecture Undocumented dependencies between potential services and user interface code have to be identified and removed SMART Case Study: Gap Analysis

99 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 99 Select Recommended Options Develop Migration Strategy: Tasks Create Migration Alternatives Table Create Migration Alternatives Table Analyze Options Present Findings What components? What services? There can be more than one viable strategy Different sequencing Use of external services Use of COTS products Estimate comparative cost, effort, and risks SMART Activities: Develop Migration Strategy

100 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial Migration Alternatives Table $K% % Q QQQ Q QQ MM N Migration Option # 1 Service Need Satisfied Option Number Migration Estimates New Development Estimates Migration Versus New Development Name of Service Need Option Summation $K% % Q QQQ Q QQ MM N Migration Option # 3 Name of Service Need Option Summation $K% % Q Q QQ Q QQ MM N Migration Option # 2 Name of Service Need Option Summation SMART Activities: Develop Migration Strategy

101 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial Outcome of SMART Summary Report RESULTS þ List of stakeholders þ List of candidate services þ Description of legacy components, target SOA þ Results of analyses þ Description of various migration options þ Cost and effort of selected options RESULTS þ List of stakeholders þ List of candidate services þ Description of legacy components, target SOA þ Results of analyses þ Description of various migration options þ Cost and effort of selected options SMART Activities: Develop Migration Strategy

102 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial Case Study: Recommendations Perform a workshop with all the key stakeholders to -Validate the expectations and requirements for the new services -Define a roadmap for the migration effort Identify services that are both important and less complex than the ones initially identified Implement these services a pilot using the current target architecture Revisit the new architecture (SOA) after the pilot phase to make changes based on the lessons learned in pilot phase Identify the order in which services should be implemented based on greatest impact with lowest risk; prioritize and plan accordingly Recalculate cost/effort when -Code dependencies are better documented -User requirements are better understood -Target SOA is better defined SMART Case Study: Migration Strategy

103 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial Agenda Introduction to SOA Pillars of SOA-Based Systems Development Migration to SOA SMART (Service Migration and Reuse Technique) Conclusions and Next Steps

104 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial Conclusions 1 SOA offers significant potential for Leveraging investments in legacy systems by providing a modern interface to existing capabilities Exposing functionality to a greater number of users They accomplish this by promoting Assembly of applications from existing services Platform and language independence Reuse of services through loose coupling Easy service upgrade due to separation of service interface from implementation Conclusions

105 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial Conclusions 2 End-to-end engineering approach for SOA requires addressing the unique challenges, risks and technical issues of three different development perspectives Applications that make use of services Services used by applications and other services Infrastructure that allows the discovery of services and the data exchange between application and services Conclusions

106 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial Conclusions 3 Reuse at the service level is more complex than reuse at module or component level Designing reusable services requires a different approach, skill set, and mindset Bigger stakeholder community because services are typically reused at organization and sub-organization level Cost of exposing legacy system functionality as services may be higher than actually replacing the system with a new SOA-based system Detailed analyses are needed Conclusions

107 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial Conclusions 4 Reuse in the services world requires Identification of needs of the target architecture Clear distinction between the needs that can be satisfied by the legacy system and those that cannot be satisfied Systematic analysis of changes that need to be made to fit into target architecture Conclusions

108 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial Conclusions 5 SMART analyzes the viability of reusing legacy components as the basis for services by answering these questions: What services make sense to develop? What components can be mined to derive these services? What changes are needed to accomplish the migration? What migration strategies are most appropriate? What are the preliminary estimates of cost and risk? Conclusions

109 © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial References Pointers to Technologies and Standards ISIS Guide to Interoperability SMART: The Service-oriented Migration and Reuse Technique References


Download ppt "Sponsored by the U.S. Department of Defense © 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 1 Pittsburgh, PA 15213-3890."

Similar presentations


Ads by Google