1 / 59

oasis-open

Learn about HP's experience with deploying and managing SOA, including the development of web services and cross-enterprise solutions. Explore the principles and benefits of SOA, and understand the consequences of not having an enterprise SOA strategy.

oshafer
Download Presentation

oasis-open

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. www.oasis-open.org The SOA Journey - Deploying and Managing SOA, a HP IT Case Study TutorialAnjali Anagol-SubbaraoChief Architect, IDM, Marketing and Direct IT, HP

  2. Polling Question #1 • What is your familiarity with SOA and Web Services • Investigation phase • Process of implementing a pilot • Developed a Web service • Developed a cross enterprise solution

  3. Overview of SOA • SOA • Web services • SOA Case Studies • Consumer Business • Identity Management • Best Practices

  4. New Demands Supplier Customer Partner Growth, profit, and value Technology Leadership Regulation/ Deregulation Continuous businesstransformation Customersatisfaction Mergers &acquisitions Evolving Business Objectives Changing Markets Innovation Economy Competition Satisfying Unpredictable Needs Business agility Pressures on the business…

  5. … result in challenges for the CIO Drive costs down Support rapid change Security Performance Emerging applications Outsourcing Improve availability Distributed systems Consumption-based costing Capacity Improvequalityofservice Mobility Increase business relevance Heterogeneity P&L contribution Deliverservices Reduce complexity

  6. Goals of SOA • Business and IT Alignment • Software design derived from an intrinsic understanding of business design • IT systems that enable business agility

  7. Definition In April 2006 The Object Management Group's (OMG ) SOA Special Interest Group adopted the following definition for SOA: Service Oriented Architecture is an architectural style for a community of providers and consumers of services to achieve mutual value, that: ● Allows participants in the communities to work together with minimal co-dependence or technology dependence ● Specifies the contracts to which organizations, people and technologies must adhere in order to participate in the community ● Provides for business value and business processes to be realized by the community ● Allows for a variety of technologies to be used to facilitate interactions within the community In March 2006 the OASIS group SOA Reference Model released its first public review draft. This defines the basic principles of SOA that apply at all levels of a service architecture, from business vision through to technical and infrastructure implementation. Service-Oriented Architecture: A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

  8. Principles of SOA ● services share a formal contract ● services are loosely coupled ● services abstract underlying logic ● services are composable ● services are reusable ● services are autonomous ● services are stateless ● services are discoverable Source: Thomas Erl; SearchWebService.com

  9. SOA shifts the way we think

  10. Implementing Enterprise SOA:A Multi-faceted Approach

  11. SOA Maturity Model

  12. Why an Enterprise SOA Strategy is Important • Create structure around federated SOA efforts – avoid IT mavericks • Provide guidance and recommendations to Business and IT teams wanting to implement SOA solutions • Manage and govern the architectural landscape – planning, preparing, and applying principles, techniques, and technologies to make the business adapt to change. • Manage semantic interoperability through Services • Reduces integration expenses • Web based SOA reduces integration expense through standardization • Increases Asset Reuse • Helps eliminate duplicate functionality • Reduces time to market • Promotes consistency • Reducesrisk • More control over business processes by business people • Improves Business Agility • Allows the business direct control of business processes to manage rapid change

  13. Consequences of not having an Enterprise SOA Strategy Within 2-3 years, we’ll have… • Mishmashed implementations of non-cohesive SOAs • Islands of architectures – fragmented business functionality & Business Processes • Vendor-defined SOA landscapes (every vendor wants to be the ‘center of the universe’) • IT will spend a lot of time in the future unwinding shortsighted solutions • Semantic mess – multiple applications exposing seemingly similar functionality • Lots of non-reusable, un-structured services that don’t enable business processes • Businesses struggle to react to change – reduced competitiveness

  14. A common source of confusion SOA Technology and Web Services • One of the key reasons for the today’s focus upon SOA is the emergence of supporting technologies. • SOA is an architectural approach, centered around the concept of services • SOA ≠ Web Services • SOA can exist without Web Services • Web Services can be utilized without an SOA • Using web services can significantly enhance our ability to implement SOA

  15. World Wide Web Consortium (W3C) http://www.w3c.org Organization for the Advancement of Structured Information Standards (OASIS) http://www.oasis-open.org WS-Interoperability (WS-I) http://www.ws-i.org Web Services Standards

  16. Web Services make implementing SOA easier, but they aren’t the same Standard architecture with Web Services SOA leveraging Web Services SOA Fabric (Abstraction Layer) Transactions Transactions Business Services Data Services Discovery Messaging Messaging Messaging Management Monitoring Security Security Security Transactions Messaging Security Web Services Web Services Web Services LegacyApp Custom App ERP Web Services Web Services Web Services LegacyApp Custom App ERP

  17. SO Maturity Strategic Benefit Business ComponentArchitecture Event Driven Dynamic business partnerships possible CompositeServices BPA-Aligned Reuse across companies; Scaled process-to-process b2b Coarse Grained Reuse within the Enterprise; process-to-process b2b Fine Grained LooselyCoupled Reuse within Organizations; Browser-based b2b TechnologyMaturity Structured Programming Business Process Execution Language Client/Server & Traditional Languages J2EE Standards/.Net MetadataRepository WS-MgmtQuality of Service SOAP;WSDL WSRP WS Security Web Services, the preferred technology for SOA • A web service exposes a SOAP XML (industry standard) interface and can be invoked by any client regardless of platform (e.g. J2EE, .Net etc.) • Ideally suited for heterogeneous IT environments (such as HP’s) to enable systems to interact in a standards-compliant, interoperable manner • Web services offer the technology and SOA offers the blueprint

  18. SOA Case Studies

  19. HP-IT Reference SOA

  20. HP-IT Reference SOA – Standards View

  21. E-Business IT – Significant Progress with SOA • Evolving to an SOA has been the core of Architecture Strategy • Progress to date • Decouple systems and eliminate the re-integration problem • Enforce greater consistency in processes and re-use • Lower cost to serve • Benefits • Greater IT agility leading to better business agility • Greater Leverage of investment dollars

  22. E-Business IT’s SOA Evolution From “monolithic” solutions… Web Site A (e.g., SMB Store) Web Site B (e.g., Enterprise) Web Site C (e.g., Public Sector) Web Site D (e.g., Consumer) Function B3 Function B4 Function A3 Function A4 Function B2 Function B1 Function A2 Function A1 Function C3 Function C4 Function C2 Function D3 Function D4 Function C1 Function D2 Function D1 Function F3 Function F4 Function E3 Function E4 Function F2 Function F1 Function E2 Function E1 Function G3 Function G4 Function G2 Function H3 Function H4 Function G1 Function H2 Function H1 Enterprise Repositories Master Data Financial CRM ERP Content

  23. E-Business IT’s SOA Evolution (2) … to “thin” service consumers that leverage web services for std processes Web Site A (e.g., SMB Store) Web Site B (e.g., Consumer eSupport) Site C (e.g., Retail Kiosk) Site D (e.g., Enterprise Procurement System) Sites Service C Service B Service A Service D Web Services exposing standard processes Service E Service F Service G Service H Enterprise Repositories Financial CRM ERP Content Master Data

  24. Consumer Business Case Study

  25. Retailer Systems Configurator, Catalog DB, Vendor data entry tools IT couldn’t keep up with business demands Retail Outlet • Not real-time • Custom developed “pipe” for each business partner was expensive to maintain • Long lead times to connect new retailers • Could not support major e-tailers hp website 3rd party systems External interface ERP (SAP) Core system

  26. Why SOA? • Service–oriented to offer a menu of services for retailers to pick and choose from • Leverage the expertise of HP and retail partners • Interoperability with disparate systems of retailers • Standard platform to expose functions from disparate HP systems • Abstracting the interface from the implementation • Reuse of services

  27. Retailer systems Web services client Request price Distribute product catalog Request basket transfer Query product info Validateconfig Place order Query order Status Web services layer Configurator, Product catalog database Request/Response technology (Application server) Data repositories Core system ERP (SAP) HP systems SOA Implementation Using Web Services Web services

  28. Overview of SOA Solution • 4 Web services in production • 12 external partners • 1st implementation – March 2002 • HP’s systems – SAP, Microsoft, J2EE, Oracle • Retailer systems – .Net, VB, J2EE – WebLogic, Web Methods

  29. Lessons Learned • Not all partners ready with XML; EDI has to be part of solution • Achieving desired performance is a challenge • Development time delayed due to evolving standards and technologies • Security and interoperability can be achieved

  30. Results Achieved – Business Agility • Increased sales (see chart) • Faster order to delivery time (24 hours) • 50% decrease in man-months to implement new accounts • Savings from closing down systems and moving to an SOA platform • New revenue streams generated by offering services like ValidateConfig Note: circles indicate months accounts transitioned to new infrastructure / program

  31. Case Study:Identity Management

  32. subsequent site layers HP.com awareness buy public sector consumer enterprise/corporate small/medium bus. Customer Experience Strategy, IA, Design use & learn support common services site infrastructure publishing systems back-end systems Overview of Customer IDM Customer IDM provides a mission critical horizontal process and shared service for hp.com web sites

  33. Industry Leading Implementation • One of the largest IDM systems in the industry • 35 MM users, growth rate of 700,000/month • One of the highest Available systems in HP • SLA of 3 9’s , protects sites which do business of the order of 4 billion dollars/year

  34. Challenges for Customer IDM system • Many ways to do registration which increased cost of implementation • Non-standard protocols for authentication • Tight coupling between client and server • Only web access management • Access through different web sites which caused security issues

  35. EXTERNAL FIREWALL Web Registration API DMZ services Web site Site Site HP Passport Plugin - auth Plugin auth Plugin - auth - Components REGISTRATION SERVER INTERNAL FIREWALL Web Services Policy Server DATABASE App Server Cluster Custom pipes to provide IDM functionality End-User Web Browser

  36. How did we resolve the challenges • To address the HP identity and access management challenges • HP-IT is implementing identity services through an SOA model. • Implementing registration, authentication and federation services • The identity services were hosted centrally and all external facing web sites could consume these common services • Loosely coupled • Interoperable across many OS/app/web servers • Uses standard protocols • Open to services, devices

  37. SOA-based Architecture - End User ( Web Browser ) Enterprise Customers Device Rich Client Web Service EXTERNAL FIREWALL DMZ Registration Authentication / Federation Web Services Services - 2 Services - 1 HP Passport Components REGISTRATION SERVER INTERNAL FIREWALL Policy Server Web Services DATABASE App Server Cluster

  38. Identity Services Defined – Burton slide Consumers of Identity Operations Federated domains Applications Applications Identity and policy administration Applications Services Federation Authentication & Authorization Query & Update Personalization & Visualization Security Underlying Identity Components

  39. Identity Services Defined – HP’s Identity Services Consumers of Identity Operations Federated domains Applications Applications Identity and policy administration Applications Services Federation Authentication & Authorization Query & Update Personalization & Visualization Security Login Validate Federation Web services EditProfile UpdateCredentials getUser Password Management Underlying Identity Components

  40. Benefits • Enabling new business opportunities • Cross selling, up selling between SMB and enterprise storefronts • Enabling extended enterprise • Identity services help bring these partners/outsourcers to have a more seamless access to HP • Extended functionality beyond web access management • Achieved a Cost Reduction of 50% • Leverage Idm to reduce business costs through identity services • Used standard protocols and loose coupling • Support, integration costs reduced • Risk Mitigation • Security Breaches avoided as one registration, authentication service used throughout company • Federation helped in maintaining regulatory compliance

  41. Best Practices/Lessons Learned

  42. Best Practices Established for SOA • Designing for interoperability • Publishing enduring Web services contracts • Effectively using business tier systems • Planning a robust production environment • Building with Frameworks

  43. Challenges – Web Services Interoperability • The great promise of web services • Service producers and consumers can use any OS / prog. language • Web services standards would guarantee seamless interoperability • Reality – Creating interoperable web services is still hard • Evolving specs and ambiguity • Vendors implementing standards selectively • Teams encounter interoperability issues (often discovered during later stages of testing) • In some cases, caused senior management to form a negative opinion of web services, and the value of SOA in general • Compiled best practices with respect to interoperability • Compliance vs interoperability (exceptions to WS-I standards) • Issues with specific vendors tools

  44. First design the interface • Use WSDL editors (XMLSpy) to create WSDL (for the validateConfig service) • Three abstract definitions - types, messages and port type • Two concrete definitions - binding and service

  45. Design considerations for Versioning • Leverage XML Schemas • Patterns to facilitate Versioning • Naming Convention • Deployment Strategy

  46. Details of versioning • Using date stamp as part of the target namespace of your XML Schema. <SOAP-ENV:Body> <m:inValidateConfigv1_2 xmlns:m="http://production.psg.hp.com/types/2004/02/04"> ….. </SOAP-ENV:Body> • Use different end points in WSDL • Use different operations

  47. Versioning Lifecycle • Build transition plan • Make Changes to Service. • Test new Service version • Implement new Service version. • Add/publish new Service version to WSDL descriptions, UDDI registries, etc. • Notify known Consumers of new Service version and transition plan • Run Service versions in Parallel • Set Date for Retirement of older Service version • Notify known Consumers of retirement • Remove old Service version from descriptions, registries etc. to stop new consumers discovering and using. • Remove functional behavior of old Service. Only return appropriate error message • Retire old Service. Physically remove old Service version.

  48. Key Security Elements • Secured the Web services using Transport Level Security – 2 way SSL • Creates performance issues • Now Web services can be secured using message level security - WS-Security

  49. Performance and Web services • Performance numbers without SSL • Performance numbers with SSL-- degradation of approx 30%

  50. Enhancing the performance • Identifying performance bottlenecks using HP’s OVTA

More Related