The SOA Journey - Deploying and Managing SOA, a HP IT Case Study Tutorial Anjali Anagol-Subbarao Chief Architect, IDM, Marketing and Direct IT, HP

1
The SOA Journey - Deploying and Managing SOA, a
HP IT Case Study TutorialAnjali
Anagol-SubbaraoChief Architect, IDM, Marketing
and Direct IT, HP
www.oasis-open.org
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
Pressures on the business
5
result in challenges for the CIO
Drive costs down
Support rapid change
Security
Performance
Improve availability
Outsourcing
Emerging applications
Consumption-based costing
Capacity
Distributed systems
Improvequalityofservice
Increase business relevance
Mobility
Deliverservices
PL contribution
Heterogeneity
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
Traditional Applications Service Oriented Architecture
Designed to last Designed to change
Tightly Coupled Loosely Coupled, Agile and Adaptive
Integrate Silos Compose Services
Detailed Abstracted
Long development cycle Interactive and iterative development
Cost, supply centered Business, demand centered
Middleware makes it work Architecture makes it work
Favors Homogeneous Technology Favors Heterogeneous Technology
10
Implementing Enterprise SOAA Multi-faceted
Approach
11
SOA Maturity Model
SOA Maturity Levels SOA Maturity Levels SOA Maturity Levels SOA Maturity Levels SOA Maturity Levels
Level 1Ad-hoc Level 2Basic Level 3Standardized Level 4Managed Level 5Adaptive
SOA Maturity Dimensions Business Minimal business interested in SOA Business is aware of SOA Business generally complies with SOA Business proactively supports SOA SOA is fundamental to business operations
SOA Maturity Dimensions ProgramManagement SOA is project focused SOA efforts are BU based SOA is federated but not integrated SOA is integrated at corporate level SOA is enterprise-wide and extends to partners
SOA Maturity Dimensions Governance Some acknowledgement of governance issues Some governance processes, individual responsibility Gov. guidelines defined integrated into process The value of governance is fully understood Advanced understanding of IT Governance
SOA Maturity Dimensions Architecture Limited or ineffective architecture Arch. program exists and architecture is defined All IT initiatives comply with the architecture Arch. Is business driven and is auditably linked Arch. and business are executed as integrated
SOA Maturity Dimensions Operations and management No mgmt of services, infrastructure elements only Mgmt of apps and infrastructure in terms of SLAs Management of business services Proactive mgmt of business svcs linked to component svcs Mgmt of business svcs integrated into biz operations
SOA Maturity Dimensions Supply and demand Biz needs are all met using technology components All services are provided internally Valued-based sourcing decisions Services sourced from multiple providers Dynamic service sourcing from multiple sources
SOA Maturity Dimensions People Staff have little or no knowledge of SOA Understanding of SOA is limited to IT mgmt and architects SOA education is required for all IT staff Ongoing SOA education is attended by all staff SOA is embraced by all staff and actively promoted
SOA Maturity Dimensions Enabling technology There is no service infrastructure in place SOA infrastructure is limited to exposing functionality as svcs Standardized enterprise-wide SOA infrastructure Large scale managed SOA infrastructure Integrated, dynamic SOA infrastructure
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
• Reduces risk
• 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, well 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
  dont enable business processes
• Businesses struggle to react to change reduced
  competitiveness

14
SOA Technology and Web Services
A common source of confusion

• One of the key reasons for the todays 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
Web Services Standards

• 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

16
Web Services make implementing SOA easier, but
they arent the same
Standard architecture with Web Services
SOA leveraging Web Services
Transactions
Transactions
SOA Fabric (Abstraction Layer)
Business Services
Data Services
Discovery
Messaging
Messaging
Messaging
Management
Monitoring
Security
Security
Security
Transactions
Messaging
Security
Web Services
Web Services
Web Services
ERP
LegacyApp
Custom App
Web Services
Web Services
Web Services
ERP
LegacyApp
Custom App
17
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 HPs) 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 ITs 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 B1
Function B2
Function A3
Function A4
Function A1
Function A2
Function C2
Function C3
Function D3
Function C4
Function D4
Function C1
Function D1
Function D2
Function F3
Function F4
Function F1
Function E2
Function F2
Function E3
Function E4
Function E1
Function G3
Function G4
Function G1
Function G2
Function H3
Function H4
Function H1
Function H2
Enterprise Repositories
Master Data
CRM
Financial
ERP
Content
23
E-Business ITs 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 A
Service C
Service B
Service D
Web Services exposing standard processes
Service E
Service F
Service G
Service H
Enterprise Repositories
CRM
Financial
ERP
Content
Master Data
24
Consumer Business Case Study
25
IT couldnt 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?

• Serviceoriented 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
SOA Implementation Using Web Services
Web services
28
Overview of SOA Solution

• 4 Web services in production
• 12 external partners
• 1st implementation March 2002
• HPs 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

1. Increased sales (see chart)
2. Faster order to delivery time (24 hours)
3. 50 decrease in man-months to implement new
   accounts
4. Savings from closing down systems and moving to
   an SOA platform
5. 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
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 9s , 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
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
Authentication Authorization
Query Update
Personalization Visualization
Security
Federation

Underlying Identity Components
39
Identity Services Defined HPs Identity Services
Consumers of Identity Operations
Federated domains
Applications
Applications
Identity and policy administration
Applications
Services
Authentication Authorization
Query Update
Personalization Visualization
Security
Federation

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.
• ltSOAP-ENVBodygt
• ltminValidateConfigv1_2 xmlnsm"http//producti
  on.psg.hp.com/types/2004/02/04"gt
• ..
• lt/SOAP-ENVBodygt
• Use different end points in WSDL
• Use different operations

47
Versioning Lifecycle

1. Build transition plan
2. Make Changes to Service.
3. Test new Service version
4. Implement new Service version.
5. Add/publish new Service version to WSDL
   descriptions, UDDI registries, etc.
6. Notify known Consumers of new Service version and
   transition plan
7. Run Service versions in Parallel
8. Set Date for Retirement of older Service version
9. Notify known Consumers of retirement
10. Remove old Service version from descriptions,
    registries etc. to stop new consumers discovering
    and using.
11. Remove functional behavior of old Service. Only
    return appropriate error message
12. 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

Transaction Name Minimum Average Maximum Std 90 Percent Pass
AB_request 0.578 2.168 34.75 2.9 3.928 1,449
placeOrder_request 3.688 6.367 29.344 2.931 9.53 193
VC_request 0.719 2.172 24.078 2.252 3.804 10,080
50
Enhancing the performance

• Identifying performance bottlenecks using HPs
  OVTA

51
Enhancing the performance

• Making XML more efficient
• Use sTAX parser
• XML Beans for XML to Java Binding (now part of
  Apache open source)
• XML accelerators from HP
• Making SOAP more efficient
• SOAP parsers
• BEA SOAP engine measurements showed 72 faster
  than Apache Axis
• SOAP with attachments

52
Frameworks support SOA

• Dealing with complexity
• Standards do not specify how to deal with the
  complexities of designing and implementing
  modular, reliable, scalable and high performance
  services
• Frameworks
• Productize best practices and provide a
  foundation to developers for creating services
• Repeatability and consistency
• E-Biz SSA framework for designing and
  implementing services
• E-Biz WPA framework for UIs that consume services

53
What next for SOA and Web Services?

• Infrastructure to support SOA ecosystem
• for sustaining
• Business Agility

Business Process Management
54
Summary

• Introduction to SOA and web services
• Successful implementation of SOA architecture
• Configure to Order Case Study
• Identity Management Case Study
• Lifecycle of development of Web services
• Challenges of implementing Web services
  security and performance
• Best Practices

55
Call to action

• Check out http//dev2dev.bea.com/index.jsp for
  BEA WebLogic references
• Look at http//openview.hp.com/bea for the
  OpenView Products
• Access DRC portal at http//devresource.hp.com
  for Web services, SOA, life cycle development
  tips
• Look at http//www.oasis-open.org/home/index.php
• Rest of it is in the book

56

• J2EE Web Services on BEA WebLogic
• by Anjali Anagol-Subbarao

57
Questions
58
(No Transcript)
59
www.oasis-open.org