• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Creating a Centralized Consumer Profile Management Service with WebSphere DataPower
 

Creating a Centralized Consumer Profile Management Service with WebSphere DataPower

on

  • 947 views

In this presentation will talk about how one of the world's leading Financial Institutions, leveraged WebSphere DataPower to provide a set of centralized consumer profile management services. This ...

In this presentation will talk about how one of the world's leading Financial Institutions, leveraged WebSphere DataPower to provide a set of centralized consumer profile management services. This central service would be leveraged by internal and external applications, and would align with enterprise marketing capabilities. The solution included a complex security model which included the following products: Tivoli Directory Server, Tivoli Access Manager and Tivoli Federated Identity Manager. We will describe how to build complex orchestrations in WebSphere DataPower, and also go through some of the performance tuning options we implemented to achieve a high degree of efficiency.

Statistics

Views

Total Views
947
Views on SlideShare
947
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Creating a Centralized Consumer Profile Management Service with WebSphere DataPower Creating a Centralized Consumer Profile Management Service with WebSphere DataPower Presentation Transcript

    • Creating a Common Consumer ProfileManagement Service with WebSphereDataPowerSpeakers:Brian Backer - Business Leader, Enterprise Architecture(MasterCard)Bin Tang – Consultant, Enterprise Architecture(MasterCard)Prithvi Srinivasan – SOA/Integration Practice Director(Prolifics)Date: May 1st 2013
    • Agenda• Introductions• Business Case for a Common Consumer Profile Service• Architecture Overview– IT Landscape before the CCRS Implementation– CCRS and the Future-state IT Landscape• CCRS Implementation – Developing Complex Composite Services– Logical Architecture– Service Orchestration Overview• WebSphere DataPower Performance Testing and Capacity Planning– Approach– Test Cases & Results• WebSphere DataPower Tuning and Optimization Options2
    • Agenda• Introductions• Business Case for a Common Consumer Profile Service• Architecture Overview– IT Landscape before the CCRS Implementation– CCRS and the Future-state IT Landscape• CCRS Implementation – Developing Complex Composite Services– Logical Architecture– Service Orchestration Overview• WebSphere DataPower Performance Testing and Capacity Planning– Approach– Test Cases & Results• WebSphere DataPower Tuning and Optimization Options3
    • Common Consumer Registration Service (CCRS)Page 4• Centralized enterprisecapabilities for managingconsumer users• Benefits– Centralized management ofconsumer identities– Single identity acrossmultiple applications– Security compliance– Eliminate redundantsolutionsOverview / Problem StatementCCRS represents the next evolution of shared services. Orchestration of a common businessprocess from the ESB.
    • Agenda• Introductions• Business Case for a Common Consumer Profile Service• Architecture Overview– IT Landscape before the CCRS Implementation– CCRS and the Future-state IT Landscape• CCRS Implementation – Developing Complex Composite Services– Logical Architecture– Service Orchestration Overview• WebSphere DataPower Performance Testing and Capacity Planning– Approach– Test Cases & Results• WebSphere DataPower Tuning and Optimization Options5
    • Landscape Prior to CCRS on the ESBPage 6
    • • Point to Point connection to credential managementservice– Inconsistent implementation• Localized User Profile Information– Consumer profile information spread acrossmultiple databases• Lead generation activities submitted via batch file– Lead generation profiles not matched with loginprofilesLandscape Prior to CCRS on the ESBPage 7
    • CCRS on the ESB LandscapePage 8
    • • Common service to manage authentication credentials anduser profile information• Common user profile repository leveraging master datamanagement platform• Service extensible for supporting traditional and single sign-on models• Service accessible from external gateway for LeadGeneration and Pre-Registration activities– Provides common consumer profile across lead gen andlogin models• Leverages ESB security and monitoring modelsCCRS on the ESB LandscapePage 9
    • Agenda• Introductions• Business Case for a Common Consumer Profile Service• Architecture Overview– IT Landscape before the CCRS Implementation– CCRS and the Future-state IT Landscape• CCRS Implementation – Developing Complex Composite Services– Logical Architecture– Service Orchestration Overview• WebSphere DataPower Performance Testing and Capacity Planning– Approach– Test Cases & Results• WebSphere DataPower Tuning and Optimization Options10
    • High Level OrchestrationPage 11
    • Registration Sequence DiagramPage 12
    • CCRS Orchestration ProxyPage 13
    • Agenda• Introductions• Business Case for a Common Consumer Profile Service• Architecture Overview– IT Landscape before the CCRS Implementation– CCRS and the Future-state IT Landscape• CCRS Implementation – Developing Complex Composite Services– Logical Architecture– Service Orchestration Overview• WebSphere DataPower Performance Testing and Capacity Planning– Approach– Test Cases & Results• WebSphere DataPower Tuning and Optimization Options14
    • Performance and Load Testing ApproachTesting should focus on observing the appliance under• Normal anticipated traffic load• Anticipated traffic spikes• And finally complete saturation (un-anticipated traffic spikes)Appliance statistics should be studied including• Number of connections• CPU/load behavior• Consumed memory• Response times• Interactional throughput at saturation15
    • What to Monitor ?• XSLT– XSLTs is probably the most common reason for low performance. It is wherecomplex business transformation logic is written, for instance the url-openextension function.• Services– Service objects like WS-Proxy/MPGW/XMLFW…• Message Flows : The message flows are categorized in 4 types:– Message: The time taken to process the request message received fromclient, plus processing time by the server, plus time taken to process theserver response by the device (The full transaction cycle).– Request: The time taken by DataPower to process the request messagebefore sending it to the server.– Server: The time taken by the server to process the request message sentto it by WebSphere DataPower.– Response: The time taken by WebSphere DataPower to process themessage received from the server before sending it back to the client.16
    • What to Monitor ? (Contd.)• Connections– You can get a snapshot of inbound, outbound and internal TCPconnections, you can also watch services listening on specific ports.• Device Utilization– It is also beneficial to watch the device metrics (CPU, Memory andSystem Usage) under different situations. This is usually done viaperiodic SNMP polling in most environments.**Monitoring System Load/Usage provides a better metric of applianceload than CPU usage.• System Usage• CPU Usage• Memory Usage• Transaction Rate• Receive and Transmit Throughput17
    • Performance Testing Usecases
    • Test Result Summary191 2 3 4 5TPS 1572 1319 654 457 31% Drop 16% 50% 30% 93%CPU 48% 48% 88% 90% 23%Memory 15% 15% 20% 76% 17%00.10.20.30.40.50.60.70.80.91020040060080010001200140016001800TPShttp -> mssl add AAA add MQ add real svc endpoint
    • Agenda• Introductions• Business Case for a Common Consumer Profile Service• Architecture Overview– IT Landscape before the CCRS Implementation– CCRS and the Future-state IT Landscape• CCRS Implementation – Developing Complex Composite Services– Logical Architecture– Service Orchestration Overview• WebSphere DataPower Performance Testing and Capacity Planning– Approach– Test Cases & Results• WebSphere DataPower Tuning and Optimization Options20
    • Tuning Options• Caching : Caching is the most important option for performance tuning, think ofthe time used for network communication, retrieval of WSDL documents orcompiling XSLT files.– XSLTs• Objects > XML Processing > XML Manager > XML Manager ->XSL cachesize– Documents• Objects > XML Processing > XML Manager > XML Manager -> DocumentCache Size/ Document Cache Count– WSDLs stored in WSRR• Control Panel > Web Service Proxy > Your Proxy->WSDL tab->WSDLSubscription->Refresh Interval– AAA Cache• Objects > XML Processing > AAA Policy > Your Policy-> AuthN/AuthZ tab-> Cache Lifetime21
    • Tuning Options (Contd.)• HTTP Persistent Connections : HTTP Persistent connections means reusingopened connection for sending multiple messages instead ofopening/closing a connection for each message, this option decreases CPUcycles, network traffic and latency.– Control Panel-> Your WSProxy->Advanced Proxy Tab->PersistentConnections = "On“ and specify persistence timeout• Streaming : It provides many advantages, one of which is decreasingmemory usage.– DP supports many types of streaming such as• execution streaming (using SAX when executing XSLTs), attachmentstreaming,• message streaming• context streaming• WebSphere MQ Queue Manager• When connecting to MQ, use "dpmq://" instead of direct MQconnection "mq://",22
    • Tuning Options – (Contd.)• Processing Rules :– PIPE and NULL Contexts• Whenever applicable use PIPE as Input and Output between twocontiguous action nodes• Use NULL as Input or Output of any action that doesnt need toproduce or use predecessor actions results– Asynchronous Rules• Limit the usage of asynchronous rules because as you canimagine parallel processing will increase CPU Utilization (ContextSwitching)– Reusable Rules• Reusable rules are often called many times from parentrules, this may introduce redundancy in action node execution– XSLT Code• Avoid using "//"; specify the node you are targeting using itsabsolute tree path• Limit the number of backend calls like url-open23
    • 24 Self Balancing: Self balance across a cluster of appliances Replace front-end IP load balancer New support (introduced in firmware version 4.0.2) enables connections to bepreserved, without loss, during failover scenario Dynamic and Intelligent Load Distribution to backend systems Replace backend load balancerFront-end IP loadbalancers not neededSelf balancing (IPspraying)Application Optimization
    • 25Provides application-aware Intelligent Load Distribution Auto-discovers application targets and distributes load using dynamic feedbackmechanism Topology learning for WAS ND and VE Uses intelligent weighted distribution algorithms based on current server load Weighted Least Connection load balancing algorithm Provides several options for enabling Session AffinityDataPower performs dynamic back-siderouting and load distribution (leveragingdynamic information from back-ends)Failure of target appliancesare masked by appropriateweighted distributionApplication Optimization
    • REST26DataPower XC10 As a Side CacheUser1532 4ClientProvider1. Client submits application request.2. DataPower XI parses request and queries XC10. On a hit, skip to step 5.3. On a miss, XI forwards request to target Provider.4. XI adds application response to XC10.5. Client receives response from XI. Easily integrates into the existing business process– No code changes to the client or back-endapplication– Simply add the side cache mediation at the ESB laye Significantly reduces the load on the back-end system byeliminating redundant requests Response time from elastic cache is in millisecondsImprovedResponse TimeImprovedLoadDataPower XC10DataPower XI AppliancesLarge Response Time
    • Questions ??
    • Thank You!!