Choice Points for e-Business

1. Choice Points Choice Pt For Enterprise Agility & Interoperability Choice Points for e-Business Approach to Linking and Switching with Context Orchestration Support Presenters: David RR Webber 301.482.2597 drrw@smartdraw.com XML eBusiness Mike Lubash 703.607.1166 Mike.Lubash@DFAS.mil XML Team Leader DoD Finance and Accounting Namespace Manager http://www.DFAS.info

2. Agenda • Overview of BCM semantics • Introduction to Context • Choice Point Approach • Implementation and Adoption

3. Stating the Business Needs Today • Creating the balance between the business community and the technology implementers - so the two work in synergy. • Roadmap - state transitions and sequencing diagrams showing what to accomplish, with accountability and decisions along the way • Collaboration - • need external view, not just internal • understanding information - not just data - because context is vital.

4. For Enterprise Agility & Interoperability

5. Understanding Context Date: circa 15681 : the parts of a discourse that surround a word or passage and can throw light on its meaning2 : the interrelated conditions in which something exists or occurs • Context is the pervasive driver to effective engineering • Providing and managing context is needed to drive dynamic process configuring and control • Knowing context is needed to ensure accurate information capture, packaging and delivery • Qualifying context is key to ensuring correct relationships between partners in a collaboration Lack of context control mechanisms is the most prominent reason why legacy e-Business systems are difficult and complex to extend and support

6. Sample Context Types • Community of interest determination • Business agreement context • Business agreement roles • Classification of artifacts context • Process selection context • Process tracking context • Transaction context • Exception handling context • Decisions context • Rules context Choices tend to be one off and embedded in code, rather than an approach from a strategic viewpoint – people don’t look outside their purview

7. Choice Point Roles Choice Points can be seen as providing three enablers for agile information exchanges: • Context that extends beyond the local decision point, and if persistence of decisions is required • Contextby refining criteria dynamically, and that may include from undetermined start points • Context requires a thread to establish and track the state of a process. So not all decisions are Choice Points; knowing the right questions to ask is critical.

8. Choice Point Components • Inputs • facts (assert and retract) • potential outcomes (allowed choices) • rules and constraints (e.g. codelists, nodes in hierarchy) • Outputs • outcome decision(s) – that link and switch • allowed choices / node paths in hierarchy • changed state(s) • additional requested actions • Choice engine technology • simple, inference, agent, backward chaining, etc • Actions • request an action from choice point • request current state of thread

9. Choice Point Overview Choice Engine Choice Pt Potential State Context State

10. Context Actions Choice Pt • Context Actions can be viewed as a decision tree or series of cascading choice points that have: • inputs through the assertion of facts • the operation of rules and constraints • that determine the outcome(s) from available choices. • Context ranges from the very simple – “if then do” style, to event handlers, to complex decision agents that operate on sets of dynamic facts. Simple Complex If-then-do Decision Agents Choice Pt. Implementation

11. Animal Classification Hierarchy This by itself only shows me the possible outcomes, not the means to determine which one to select.

12. Solution – Cascading Hierarchy

13. Applied to Information Architecture Context Examples… 4 Collaboration Agreements, MOA 5 Specific Ontology Navigation 11 Business Processes 3 Transaction Handling 10 2 6 Content Rendering 1 9 Codelist subsetting 8 Services; Transaction Processing 7 Communities of Interests - CoI Context at Each Information Layer

14. Service-Oriented Architecture • The choice point approach lends itself to today's Web service technology. • A choice point can function as a web service, or set of web service calls, that provide dynamic control and predeterministic decision making. • Or the choice point can be a local component that references assertions and facts as input from a web service. • Typical uses include tracking and controlling business processes, building transaction content and providing status of discreet events. SHIFT SHIFT Ad Hoc Hub n’ Spoke Service-Oriented (SOA)

15. Cascading e-Business Choices

16. Choice Point Business Summary Choice Pt Choice Pt Choice Pt • Allows templates, documents, and exchange decisions based on set of options - built declaratively • Allows inputs to determine outcomes based on rules • Choice points can call other choice points • Delivers loose-coupling, but with predeterministic tracking Applying to constructing BCM Templates… Contract – Collaboration Partner Specific Constraints Legacy systems Business Drivers: Model / Process / Constraints Business Goals Authoritative Sources

17. Choice Pt Implementing Choice Points Technology Details

18. Implementing Choice Point • A variety of rule engine solutions are available • Common needs include: • Fact assertion / retraction • Rule assertion / retraction • State tracking mechanism • Storage of current state decision memory • Decision testing support (if then analysis) • Solution determination via backtracking supported • Audit trail and decision verification (why?)

19. Choice Point Technical Features • Assertion of facts and/or rules can be passed as inputs to a choice point, and also inherited • Choices can be simple fixed set, or could be dynamic set • Choice points are exposed as components of the architecture and not closed as inaccessible within a solution • Choice points can be managed via an ontology and registry • Choice points can communicate via web services and messaging as needed • Choice points can hold the transient state of interactions

20. Technology Requirements • BCM can define neutral set of mechanisms that implementers can then construct using popular rule engines and XML formats • Interoperability prime requirement via common mechanisms and shared interfaces • Ability to use a broad set of communications via service definitions like WSDL • Can be used by other OASIS specifications to provide dynamic context driven behaviours. examples: BPEL, BPSS, CAM, CPPA, UBL, CIQ

21. Neutral Components • Rule base and consistent decision mechanisms • Fact base and consistent representations • Business-friendly rule constructs, semantics and syntax • State tracking and ability to assign globally unique thread IDs • Query and Response action formats • Change action formats • Event handling formats • Security support with audit trail

22. Example Rule EngineDesign Choice Pt

23. Example Decision Detail

24. Next Steps • Solicit vendor participation • Create Linking and Switching SC of BCM TC and invite participation – review earlier work (SHOE, RuleML, BRML, etc) • Liaison with OASIS TCs to refine requirements and implementation model • Creation of W3C WSDL model for choice points • Development of technical specification (Pareto principle applies!) • Prototype using available rule engines • Demonstration using selected business scenarios

25. Communities of Interests Ontology Choice Pt Architecture Processing http://www.DFAS.info