Business Layers

1
Business Layers
Defining Simple Open Interchange Constructs
Task Force DoD Namespace
February 12, 2002 Workshop
2
Consensus is extremely difficult
so we need to look for other ways,
complementary mechanisms for alignment.
3
Standardizing of APIs Constructs

• Influences
• XML/edi Framework
• CommerceNets eCo Architecture
• Hewlett Packards eSpeak
• Global Uniform Interoperable Data Exchange
  GUIDE
• SEF/IMDEF Implementation Guideline Markup
  Language (igML)
• Universal Registry - UREP XMI
• Current Work
• ISO/IEC 11179
• ebXML Specifications
• eBTWG on going

4
Construct Components
Address
Component
Meets business requirements
5
Model for Mechanisms
Collaboration Partner Agreements
Collaboration Partner Profiles
5
Contract
Workflow
4
BP Specification
Process
XForms
Specifications Schema
3
Messages
Assemblies
Artifact relationships
Motivation Time People
2
Presentation
Rules
Events
Roles
Directory Services
Data/Codes Services/Functions
Network
1
MSH/SOAP
Verbs
Transport Routing, Packaging
Nouns
WSDL
Source Lubash Pyramid
6
Registrys Role Open Active Mechanisms
5
DoD XML Registry
Contract
Open Constructs
Workflow
4
Process
Specifications Schema
3
Messages
Artifact relationships
Motivation Time People
2
Presentation
Rules
Events
Roles
Directory Services
Data/Codes Services/Functions
Network
1
Verbs
Nouns
Transport Routing, Packaging
Open API
7
Realizing the Full Benefits of eBusiness
Mapping (Today)
Templates (Future)
App
App
Std
Domain
Trans
Trans
IC
Map
Instance
IC
Instance
Template
Specific
Across Domain
Trans
Map
Registry Preferred
App
App
8
Open API/Constructs allows for Help From Above
Collaboration Partner 1
Collaboration Partner 2
Business
Information
DoD SHADE Registry
XML Instance
XML Instance
Data
ltItemNogt41358lt/ItemNogt
ltUnitNogt41358lt/UnitNogt
ltColorgtGreenlt/Greengt
Machine-to-Machine
9
Assembly Doc Addresses Level 3 Needs
Collaboration Partner Agreements
Collaboration Partner Profiles
5
Contract
Workflow
4
BP Specification
Process
XForms
Specifications Schema
3
Messages
Assemblies
Artifact relationships
Motivation Time People
2
Presentation
Rules
Events
Roles
Directory Services
Data/Codes Services/Functions
Network
1
MSH/SOAP
Verbs
Transport Routing, Packaging
Nouns
WSDL
Source Lubash Pyramid
10
Core Component Realisation (CCR)

• Assembly Doc
• Approach and Technical Details

11
Assembly DocObjectives and Focus

• Introduction
• Provide linkage between architecture design stack
  and payload formats.
• Design Constraints
• Suitable for use by technical business users, not
  just programmers
• Re-use of XML specifications toolset
• Support use of Core Components
• Provide Registry facilitation
• Provide support for legacy transaction formats
• Support BPSS provision for substitution
  transaction formats

12
Architecture Components
13
Implementation Overview
Design Time
UML / XMI
Context
AssemblyDoc
Content Map
14
Business Needs

• Ensure that the logical model and the physical
  implementation are tightly coupled
• Lesson learned developing standard examples
  leads to gap between what people actually use.

15
How do we implement this?
What technology pieces work and how do we
leverage them?
16
Technology Toolbox

• Schema / DTD describe the structure set but
  weak at describing the instance set, ie (A,B
  AB A B)
• Old IMPDEF how UN/EDIFACT does this stuff for
  EDI, but no good for XML
• XSLT procedural tool, good for XML, not others
• Schemotron / Examplotron validation-centric
• Simple well-formed XML more expressive than
  DTD!
• XPath good tool for describing constraint rules
• Need declarative approach not procedural
• No runtime surprises! All content must be
  pre-determined.

17
Technical Approach

• Need the 3 pieces
• Structural definition
• Neutral XML means to define actual instance model
• Constraint rules
• Use XPath
• Use Examplotron style in-line action statements
• Use Declarative predicates
• Content Referencing
• Registry based
• In-line based

18
AssemblyDoc A, B, C!

• ltAssemblyDocgt
• ltAssemblyStructuregt
• ltBusinessUseContextgt
• ltContentReferencegt
• lt/AssemblyDocgt

19
AssemblyDoc Structure Details

• ltAssemblyDocgt
• ltAssemblyStructuregt
• ltPOST_JOURNAL asidJournalDetails gt
• ltJEHEADERgt
• ltAMOUNT qualifier"DOCUMENT" type"T"gt
• ltVALUEgt2340500lt/VALUEgt
• ltNUMOFDECgt2lt/NUMOFDECgt
• ltSIGNgtlt/SIGNgt
• ltCURRENCYgtUSDlt/CURRENCYgt
• ltDRCRgtDlt/DRCRgt
• lt/AMOUNTgt
• ltDATETIME qualifier"DOCUMENT" type"T"gt
• ltYEARgtlt/YEARgt
• ltMONTHgtlt/MONTHgt
• ltDAYgtlt/DAYgt
• ltHOURgtlt/HOURgt
• ltMINUTEgtlt/MINUTEgt
• ltSECONDgtlt/SECONDgt
• ltSUBSECONDgt0000lt/SUBSECONDgt

Start with what you want!
20
AssemblyDoc Context Details

• ltAssemblyDocgt
• ltAssemblyStructuregt
• lt/AssemblyStructuregt
• ltBusinessUseContextgt lt!-- optional section to
  configure structure assembly template --gt
• ltRulesgt
• ltcontextgt lt!-- default structure constraints
  --gt
• ltconstraint action"makeoptional(//MetaInforma
  tion/annotation)" /gt
• ltconstraint action"makerepeatable(//Associati
  on)" /gt
• ltconstraint action"makeoptional(//Association
  _at_registry)" /gt
• lt/contextgt
• ltcontext condition"token'ComponentType' and
  contains(value,'noun')"gt
• ltconstraint condition"/token'use' and
  /value'element'" action"excludeTree(//Processes)
  " /gt
• lt/contextgt
• ltcontext condition"token'ComponentType' and
  contains(value,'logical')"gt
• ltconstraint action"excludeTree(//PhysicalDeta
  il)" /gt
• ltconstraint action"makeoptional(//PhysicalDet
  ail)" /gt
• lt/contextgt
• lt/Rulesgt

Also can use includes to pull in the rules
instead in-line
21
Context Rules Functions

• Small set declarative approach to controlling
  instance
• excludeTree (XPath)
• excludeElement (XPath)
• excludeAttribute (XPath)
• makeoptional (XPath)
• makemandatory (XPath)
• makerepeatable (XPath)
• useChoice (XPath)
• setValue (XPath,string)
• restrictValues (XPath,UIDstring,string..)
• replaceValues (XPath,UID(match,replace),(mat
  ch,replace)
• Supports use of logic analyzer to detail
  parameters / rules, and also pretty print for
  business designer / analyst.

22
Content Reference Section

• ltContentReferencegt
• ltitem name"Label" UIDReference"UNCC010015"
  taxonomy"UID" registry"UNCC" /gt
• ltitem name"City" type"text" maxLength"30" /gt
• ltitem name"Description" UIDReference"UNCC01001
  6" taxonomy"UID" registry"UNCC" /gt
• ltitem name"ExtensionDefinitions"
  UIDReference"UNCC010017" taxonomy"UID"
  registry"UNCC" /gt
• ltitem name"PhysicalDetail" UIDReference"UNCC01
  0018" taxonomy"UID" registry"UNCC" /gt
• ltitem name"Constraints" UIDReference"UNCC01001
  9" taxonomy"UID" registry"UNCC" /gt
• ltitem name"ExtendedDetails" UIDReference"UNCC0
  10023" taxonomy"UID" registry"UNCC" /gt
• ltitem name"Processes" UIDReference"UNCC010024"
  taxonomy"UID" registry"UNCC" /gt
• ltitem name"Associations" UIDReference"UNCC0100
  25" taxonomy"UID" registry"UNCC" /gt
• ltitem name"Association" UIDReference"UNCC01002
  6" taxonomy"UID" registry"UNCC" /gt
• ltitem name"Schemas" UIDReference"UNCC010027"
  taxonomy"UID" registry"UNCC" /gt
• ltitem name"Context" UIDReference"UNCC010028"
  taxonomy"UID" registry"UNCC" /gt
• lt/ContentReferencegt

23
From AssemblyDoc to Content Map

• The AssemblyDoc defines the structural formatting
  and the business rules for the transaction
  content.
• This then drives the implementation step of
  linking the derived final contextual details to
  the actual application information.
• Declarative approach stating input / output
  path locations.

24
Example content map

• ltMapStructuregt
• ltRulesgt
• ltMapRule output"Product List"
  input"_at_PARENT()" path"" /gt
• ltMapRule output"type" input"Sales/Company/Yea
  r/Qrt/Product_at_type" /gt
• ltMapRule output"name" input"Sales/Company/Yea
  r/Qrt/Product/Item_at_name" /gt
• ltMapRule outputmadeby" input"Sales/Company/Y
  ear/Qrt/Product/Item_at_manf" /gt
• ltMapRule output"value" input"Sales/Company/Ye
  ar/Qrt/Product/Item_at_value" /gt
• ltMapRule output"sold" input"Sales/Company/Yea
  r/Qrt/Product/Item_at_sold" /gt
• ltMapRule output"Product List"
  input"_at_ENDPARENT()" /gt
• lt/Rulesgt
• lt/MapStructuregt

25
Summary

• Uses well-formed XML structure with in-line
  directives to describe content model and supports
  legacy formats.
• Uses XPath and declarative predicates to state
  the MIG (message implementation guidelines) in
  machine accessible format.
• Couples to the business context of BPSS / CPA via
  partner parameter profile document and link from
  the BPSS.
• Allows for localization and substitution
  structures
• Provides referencing to component semantics in
  registry or inline locally.
• Makes consistent assembly possible, and drives
  adoption of simple transaction structures.

26
UN/CEFACT
SIMPLE, TRANSPARENT AND EFFECTIVE PROCESSES FOR
GLOBAL BUSINESS.