© 2015 IBM Corporation
2475 - Best practices in IBM Operational Decision Manager TopologiesPierre FEILLET – ODM Product Architect [email protected]
Agenda
• What’s new in ODM 8.7.0• ODM Standard Architecture & runtime elements• Recommended topologies• Decision Service Development Lifecycle• Business Rules everywhere• Best practices
2
ODM 8.7.0 Editions• Standard
• Decision Center• Decision Server Rules
– Coming from ILOG JRules– Mostly stateless decision– Decision Runner– Decision Service projects– HTDS extended to RES/JSON exec
• Advanced = Standard +• Decision Server Event
– Continuation of WebSphere Business Event– Stateful execution – Event driven– WAS ND cluster with XS
• Decision Server Insights– Dynamic modeling to define Events, Entities & detection rules to search
for situations– Server Grid with events & data in memory– WAS Liberty + WXS
4
ODM Standard - Concept of Operations
6
Decision Server
Development
Operation
Continuous Improvement
Rule ExecutionServer
JEE/J2SE
Rule Designer(Eclipse)
Decision Center -Decision Validation Services
z Rule ExecutionServer
COBOL
Decision Center Repository
IT ArchitectIT Developer
Business AnalystProcess Owner
Business UserBusiness Leader
Code Generation
Deploy
Synchronize
ODM Standard Component Organization
7
•Designer• Decision Center
• Business Console• Enterprise Console
•Decision Server Rules• Rule Execution Server
• Rule Execution Server web console
• Hosted Transparent Decision Service
• Scenario Service Provider• Decision Warehouse• Rule Sessions• eXecution Unit
ODM Standard Component List
8
Component Acronym Description DB tables SIBus
Decision Center DC Web consoles + the DM authoring repository to store rule and event projects
Decision Center tables None
Decision Server / Rule Server Console
RES Console Executable Decision Service mgt through RuleApp/ruleset assets
Rule Execution Server tables
None
Decision Server / Rule eXecution Unit
RES XU Rule server core runtime deployed as JCA or Pojo Rule Execution Server tables
None
Decision Server / Rule Sessions
Rule Sessions
Rule runtime components available as EJBs or Pojo None ODM Bus
Decision Server / Decision Services
Custom or OOTB JEE artifacts that encompass the invocation and the decision logic (RuleApp/Ruleset). Are based on Rule Sessions.
None None expected unless MDB used
Decision Server / Scenario Service Provider
SSP Test and simulation rule runtimeDecisionRunner war added in 8.7.0 for new Simulation
None None
Decision Server / HTDS HTDS Dynamic Web Services None None
Decision Server / Decision Warehouse
DW Runtime that listens and store decisions Decision Warehouse tables
None
A full fledge Enterprise Proposal
9
System z Enterprise 196 (or 114) +
LPAR, Sysplex
100% Java product on distributed plus a native secret sauce in zRES
OS Distributed including
z/Linux z/OS
Power or Intel bladesz/VM z/OS
z/Linux
WAS ND
& LWAS ND
CICS
ODM ODM
distributed
WAS ND Other AS
Works with a variety of stacks WAS ND, WAS Liberty profile (8.5.5.3) on distributed & z/OS zRES Lightweight server for z/OS, run standalone and in
CICS JSE Rule Execution Server & rule engine
ODM
ODM Technical Detailed System Requirements
Distributed
WAS
Liberty
WAS
Liberty
ODM Standard Consoles & Touch Points
10
Decision Center
Decision Server
ODM cell
Rule Designer
Decision Center Consoles
Desktop
WAS Administration Console
Rule Execution ServerConsole
DC Ant Tasks
DS Ant Tasks
Synchro over HTTP(S)
Executable artifact deploymentover HTTP(S)
All Consoles, synchronization, deployment going through HTTP(S)
HTTP(S)
HTTP(S)
HTTP(S)
HTDS WS endpointsHTTP(S)
Zoom on Decision Server / Rule Architecture
11
RuleApp & Ruleset archive deployment
Rule Sessions EJBPOJO
Engine JCA
CustomDecision Services
eXecution Unit
Management Console
RuleApp/Ruleset Repository
EngineEngine
Mgt Notification
JMX/IP
Management Model
Decision Warehouse DB Decision
Traces
SSPTesting & Simulation backendIncludes
DecisionRunner
JMX
11
HostedTransparent
DecisionServices
WS WS, JSE, Message, your choice
RES Console
• Workload• Only management of the rule executable artifacts (RuleApp,
ruleset, eXecutable Object Models)• Execution restricted to diagnostic and interactive testing• Notification to eXecution Units when a new artifact comes
available• Design
• In memory stateful webapp on the top of the RES DB• Contains a JMX Model
• Kind of WAS Deployment Manager for Decision Services
12
RES What If Scenarios
• What if RES Console shuts down• What do we loose
– Deployment of new ruleapps/rulesets versions through HTTP(S)– REST Mgt API become unavailable– Execution statistics are on hold
• What do we keep– Rule execution remains fully operational– Direct deployment to the RES DB remains possible
• Restart to dynamically get back these functionalities• What if RES DB goes down
• XUs will not be able to read rulesets asked but not in memory• Execution remains fully operational for all rulesets already in
memory
13
RES Console In or Out a Cluster
• Deployed in a cluster• Shared RES DB• Pros
– Included in a Decision Server cluster – no adhoc server– No SPOF
• Limitations– RuleSession Interceptor not supported– 1 only RES Console diagnostic supported at a time
• Diags run in parallel not supported– Round robbin load balancing dispatches deployed artifact deployed
over http(s) across the different RES Consoles• All deployed artifacts are stored into the shared DB• Must refresh each RES Console with the DB to see the artifacts
deployed through the other RES Consoles– Imply a local deployment flag for the SSP
14
RES Console In or Out a Cluster
• Deployed apart a cluster• Install the RES Console on a separated server• Pros
– All features supported– All deployments go to the singleton web app and underlying DB
• Cons– Needs a dedicated server– SPOF but with limited impact if it fails
15
RES Notification Protocol
• IP• RES Console hostname/IP & port number specified in each
eXecution Unit to get notified• JMX
• Works in a WAS Cell or equivalent giving a JMX MBean server federation
• RES Console defines its RES model top level MBean• Each XU defines its MBean
16
How to choose your ODM topology
18
What is my Decision Management scope?
Decision servicesSituation detection
Dev phase
Dev Integration Testing ProductionHA/DR
What is the workload nature ?
Event processing Remote/Local decision execution
Business decision Validation through Simulation and Testing
What is the platform?
distributed z: z/OS, z/Linux Hybrid Cloud
User Testing PreProd
ODM Standard Topology cheat sheet• Abbreviations for product scopes
• ODM: Full platform• ODMR: Rules only• ODME: Event only• ODM/DC: Decision Center• ODM/DS: Decision Server• ODM/DSR:DS for Rules only
• WAS ND topology concepts• ODM Profile templates delivered for
clustered DC & DS
19
Cluster
DMGRNode Agent
Server
Server
Node Agent
Server
Server
Dmgr’s nodeCustom nodeCustom node
Cell
ODM CopperDC + DS combined in a standalone server
ODM Bronze1 cell with 1 DC server + 1 DS Server
ODM Silver1 cell with a single cluster for DC & DS
ODM Gold topology1 cell with a DC cluster & DS clusterSeparation between business authoring from executionCover all product usage including business authoring, execution and simulation for rule and event Best tradeoff between Performance, HA, and cost
Platinum topologies All upper topologies that provide more workload separation and usage specialization Client App cluster can be added in this cell or run in a separated cellSimulation is isolated from business authoring & pure execution
ODM Topologies at a glance
Cell
ODM Standard Gold topology: DC + DS clusters + RES Console
Node Agent
Cluster Member 2XU, SSP, HTDS, in option Custom Decision Services developed on RES Rule Sessions
Cluster Member 1Decision Center
Deployment Manager
Node Agent
Cluster Member 3Decision Center
DecisionCenterCluster
Decision ServerCluster
Cluster Member 4XU, SSP, HTDS, in option Custom Decision Services developed on RES Rule Sessions
Decision Center DB
Decision Server Rule
DB
Decision Warehouse
DB
IP Sprayer
IHS
Server 1RES Console
• Functional separation/isolation of workload
• Several cells for staged dev lifecycle
• RES XU deployed at Node level
• Datasources deployed at cluster level
• SSPs are directly referenced on each member from DC
• Remote ClientApp cluster run in another cell or can be added to the ODM cell
• Failover• Similar types of
workloads grouped together
• Can scale individual clusters as needed
Cell
ODM: DC + DS + RES Console + Remote Client App clusters
Node Agent
Cluster Member 3XU, SSP, HTDS, in option Custom Decision Services developed on local RES Rule Sessions
Cluster Member 1Decision Center
Deployment Manager
Node Agent
Cluster Member 4Decision Center
DecisionCenterCluster
Decision ServerCluster
Cluster Member 6XU, SSP, HTDS, in option Custom Decision Services developed on local RES Rule Sessions
Decision Center DB
Decision Server Rule
DB
Decision Warehouse
DB
IP Sprayer
IHS
Server 1RES Console
• Functional separation/isolation of workload
• Several cells for staged dev lifecycle
• RES XU deployed at Node level
• Datasources deployed at cluster level
• SSPs are directly referenced on each member from DC
Cluster Member 2Client Apps invoking remote Decision Services
Cluster Member 5Client Apps invoking remote Decision Services
RemoteClient App
Cluster
Cell
ODM Standard – Decision Center cluster
Cluster Member 1Decision Center
Deployment Manager
Cluster Member 2Decision CenterDecision
Cluster
Decision Center DB
Node Agent Node Agent
Cell
ODM Standard - Gold Decision Server
Node Agent
Cluster Member 1XU, SSP, HTDS, in option Custom Decision Services developed on RES Rule Sessions
Deployment Manager
Node Agent
Decision ServerCluster
Cluster Member 2XU, SSP, HTDS, in option Custom Decision Services developed on RES Rule Sessions
Decision Server Rule
DB
Decision Warehouse
DB
IP Sprayer
IHS
Server 1RES Console
• Functional separation/isolation of workload
• Several cells for staged dev lifecycle
• RES XU deployed at Node level
• Datasources deployed at cluster level
• SSPs are directly referenced from DC
• Remote ClientApp cluster run in another cell or can be added to the DS cell
Cell
ODM Standard - Single cluster
Cluster Member 1Decision Center,XU, HTDS, SSP,Potentially customer Decision Services based on Rule Session API
Deployment Manager
Cluster Member 2Decision Center,XU, HTDS, SSP,Potentially customer Decision Services based on Rule Session API
Application &
DecisionCluster
Decision Center DB
Decision Server Rule
DB
Decision Warehouse
DB
• RES XU deployed at Node level
• Datasources deployed at cluster level
• SSPs are directly referenced on each member from DC
Server 1RES Console
Node Agent Node Agent
Cell
ODM/DSR - Testing & Simulation clusterDeployment Manager
Decision Server Rule
DB
IP Sprayer
IHS
Cluster Member 1XU, SSP
Cluster Member 2XU, SSP
Test & SimulationCluster
Server1RES Console
Node Agent Node Agent
• RES XU deployed at Node level
• Datasources deployed at cluster level
ODM Standard - Standalone server
ServerDecision Center, XU,
SSP, HTDS, potentially custom Decision Service
Apps developed based on RuleSession API
Decision Center DB
Decision Server Rule
DB
Decision Warehouse
Full ODM Standard running in a single serverIncludes all runtime parts for web decision authoring, test and execution
ODM - 2 servers
ServerDecision Center
Decision Center DB
ServerRES XU, HTDS,
potentially customer Decision Service based on the RuleSession API
Decision Server Rule
DB
Decision Warehouse
Decision Center Decision Server
Decision Center on single server + Decision Server single server2 servers environments:
• no failover• 2 minimal # of JVMs• easy to create (create standalone profile) • Automatic DB creation
Operational Decision Management Scope
Functional restriction
Project Phase
Recommended Topology
ODM Standardmeaning DC + DS for Rules
Dev ODM - standalone
Test ODM – from 2 servers to DC + DS cluster (Gold)
Prod ODM DC + DS clusters (Gold)
ODM / Decision Center Dev ODM/DC standalone
Test ODM/DC 1 cluster
Prod ODM/DC 1 cluster
ODM / Decision Server Dev ODM/DS – standalone
Test ODM/DS - 1 cluster
Prod ODM/DS – 1 to 4 clusters
ODM/Decision Server for Rule Rule Dev ODM/DSR – standalone
Test ODM/DSR – 1 cluster
Prod ODM/DSR – 1 or more clusters
Rule Simulation Dev ODM/DSR/TS – standalone
Rule Simulation Prod ODM/DSR /TS– 1 cluster
ODM Standard Topology Catalog
Decision Management Development Life Cycle
In a strict isolation required between types/purposes of environments:• DEV: application developers have access to “DEV” only , purpose is application dev and basic function testing• SIT: integration testers have access to “SIT” only, purpose is integration and function testing• User Acceptance Test: user acceptance testers have access to “UAT” only, purpose is user testing• PREPROD: function and integration proven in earlier environments, purpose of this env is largely perf testing• PROD - apps were proven in earlier environments. Barely anyone has access to this env, it is tightly regulated.
DEV SIT UAT PREPROD PROD
DEV SIT UAT PreProd PROD
Decision Management Life Cycle Features are deployed in phased environment depending on purpose Business authoring
Business Object Model and Rule Editing Business Simulation & Test
Create and run Business Test Suites and Simulation to guide and improve decision logicChampion/Challenger comparison on KPI computation
ExecutionDecision run
Business Authoring
Execution
Business Simulation & Testing
DEV SIT UAT PreProd PROD
Classic Decision Management Life Cycle Development of delimited Decision Services Business Authoring stopping most likely at UAT Business Simulation used until PreProd max
Business Authoring
Execution
Business Simulation & Testing
Agile Decision Management Life Cycle
Agile ODM Provide an ODM as a PaaS with change/extension of the decision logic without
starting back from Dev environment LOB leverage business authoring, simulation and apply their corporate decision
logic on their data Business Authoring and Simulation available in PreProd and even Prod More agility coming with more risk in production
Need governance and workload isolation to handle business authoring, simulation and execution and avoid regressions
DEV SIT UAT PreProd PROD
Execution
Business Simulation
Business Authoring
ODM Deployment across phases
Each life cycle phase is mapped into an environment Each environment is a WAS cell (or equivalent in other AS) Decision Server deployed in isolation by phase Decision Center can be shared or isolated per phase
1 or more cells dedicated by phasePhase environment contain 1 DC (cluster) when business authoring required or
1 unique shared Cell with Decision Center + multiple Cells for Decision Server
This configuration is the most commonly usedMultiple DC are possible for sandbox
Shared DC across environments• One Decision Center managing multiple Decision Servers• DC clustered with a HA/DR DB• User access, Branches mgt for multi team/releases activities• DC and DS can be split into 2 isolated envs• Online and offline RuleApp/Ruleset deployment supported in DS
Decision Center
Decision Server
DC env
Decision Server
DS env
DM for Dev DS for Integration
Testing
Executable Decision artifact deployment over HTTP
Decision Server
DS env
Decision Server
DS env
DS for Business
Simulation and
Testing
DS for PreProd
Decision Server
DS env
DS for Productio
n
DS env
SDLC – Shared Decision Center
Pros One source of truth for business rule authoring Deploy on all Decision Servers; Multiple DS/RES are supported by DC HA with DC and DS in cluster Leverage project branch and merge in DC and deploy executable rules on the various DS Access to projects and DS scoped by groups & users in DC Isolation is preserved for the execution runtime
Cons Doesn't allow DC customization for one phase only (Dev, Test or Prod)
Comments Applied by most customers Leverage clustering and HA/DR DB
Best practice is to minimize the number of DCs and have 1 source of truth
Decision Center
Decision Server
ODM env
ODM for Dev
Decision Center
Decision Server
ODM env
ODM for Integration
Testing
Decision Center
Decision Server
ODM env
ODM for PreProd
Decision Center
Decision Server
ODM env
ODM for Production
ODM Standard Fully isolated environments
Project Export/Import
Executable artifact deployment
Decision Center
Decision Server
ODM env
ODM for Business
Simulation & Testing
One Decision Center per environmentDC Synchronization through Rule Designer Export/Import of Rule Projects between DCsExport/Import of RuleApps between DS/RESsDC and DS/Simulation in PROD depending on the Agility level
SDLC – Full Isolated Environments
ProsIsolation. We have a full ODM Standard runtime in a single cellHA with DC and DS when clusteredIsolation of authoring and execution by phase and cell
ConsMultiplication of JVMs1 DB per DC to administrateDC Repository content has to be synchronized across cells from Dev cell to Prod cellDS Repository is exported/imported, or rebuilt from Decision Center or Rule DesignerEach Decision Center will have its local version of Rule & Decision projects
CommentsThis pattern is applied by clients who privilege a full ODM Rule environment
including possibly Rule Designer at each phase of the governance cycle.
zRule Execution Server Stand-alone WebSphere Application
Server for z/OS
WOLA
CICS
COBOL Application
Rule Execution Server for WAS for z/OS
COBOL <-> JavaMarshaller
COBOL Generation
Rules
GeneratedCOBOL
JVM ServerzRES
zRule Execution
Server
IMS
COBOL Application
z/OS Batch
COBOL Application
COBOL Generation
Rules
GeneratedCOBOL
COBOL Generation
Rules
GeneratedCOBOL
DS StubDS Stub DS Stub
Decision invocations flavors in z/OS
1 2
3
1
3
2
zRES
RES on WAS on z/OS
COBOL gen
3 options
ODM in the Clouds• ODM Patterns
• in PureAS (client IT)• In Pure Service (SoftLayer)
• Bluemix Business Rules• A subset of ODM ready to use in Pay as you Go approach• Deploy your decision services in a PaaS• Based on Cloud Foundry• RES Console + HTDS + Rule Designer update site
Wrap up• ODM 8.7.0
• Standard for decision services• Advanced for situation detection with Decision Server Insights
• ODM Standard• Target stateless decision services• Versatile platform running on distributed, z/OS & clouds
– Run the same business rules everywhere• Open to platform combinations:
– ex DC in distributed + DS in distributed + zRES on z/OS– ex DC & DS in Pure Service + zRES
• Decision Center & Decision Server come with their own repository and are independent– DC & RD build and deploy executable rule artifacts to DS– All execs performed in DC, or RD for dev only– Testing and simulations are triggered from DC and delegated to DS
43
Best Practices
• Prefer 1 shared DC + multiple DS dedicated per env• Use the branch/merge for handle team collaboration & multiple
releases• Additional DCs are possible but adding artifact lifecycle mgt
complexity• 1 WAS Cell per stage env with DS• Leverage AS cluster for preprod and production envs• Add DB HA/DR for DC and DS production envs• Use collocated DC+DS for standalone dev envs• Make a dedicated simulation env when this workload become
significant
44
Best Practices
• Privilege a single RES Console that would be automatically restarted if a failure occurs
• Choose your RES notif in Decision Server• JMX notification when RES Console & all eXecution Units are
in the same AS admin scope (WAS cell or equiv)• IP notif when running on JEE/JSE without JMX federation
45
Wrap up
• Tell us if you are interested in new platforms & languages: embedded, mobile, Javascript in web browser
• Help the Lab by entering RFEs to push for a full RES Console cluster support
• For more• ODM topology DevWorks article• ODM Performance Redbook
46
Notices and DisclaimersCopyright © 2015 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM.
Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS document is distributed "AS IS" without any warranty, either express or implied. In no event shall IBM be liable for any damage arising from the use of this information, including but not limited to, loss of data, business interruption, loss of profit or loss of opportunity. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided.
Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice.
Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary.
References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business.
Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation.
It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law.
Notices and Disclaimers (con’t)
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM expressly disclaims all warranties, expressed or implied, including but not limited to, the implied warranties of merchantability and fitness for a particular purpose.
The provision of the information contained herein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right.
•IBM, the IBM logo, ibm.com, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.