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

2. 2 Agenda Overview of BCM semanticsOverview of BCM semantics Introduction to ContextIntroduction to Context Choice Point ApproachChoice Point Approach Implementation and AdoptionImplementation and Adoption

3. 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. 4 For Enterprise Agility & Interoperability

5. 5 Understanding Context 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 Date: circa 1568 1 : the parts of a discourse that surround a word or passage and can throw light on its meaning 2 : the interrelated conditions in which something exists or occurs

6. 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. 7 Choice Point Roles 1.C ontext that extends beyond the local decision point, and if persistence of decisions is required 2.Context by refining criteria dynamically, and that may include from undetermined start points 3.Context requires a thread to establish and track the state of a process. Choice Points can be seen as providing three enablers for agile information exchanges: So not all decisions are Choice Points; knowing the right questions to ask is critical.

8. 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. 9 Choice Point Overview Choice Engine Context State Potential

10. 10 Context Actions 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 Implementation Choice Pt.

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

12. 12 Solution – Cascading Hierarchy

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

14. 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 Hub n’ Spoke S ervice- O riented (SOA) Ad Hoc

15. 15 Cascading e-Business Choices

16. 16 Choice Point Business Summary 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 Business Drivers: Model / Process / Constraints Contract – Collaboration Partner Specific Constraints Business Goals Legacy systems Authoritative Sources Applying to constructing BCM Templates…

17. 17 Implementing Choice Points Technology Details

18. 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. 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. 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. 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. 22 Example Rule Engine Design

23. 23 Example Decision Detail

24. 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. 25 Communities of Interests Ontology Architecture Processing http://www.DFAS.info