Copyright OASIS, 2005 / 2007
Slaying the
Complexity Monster
David WebberChair OASIS CAM TC
Presentation January 24th, 2007
Reston VA
Toward Agile Information Services
Overview Part 1 – Introduction (10 mins)
Business Information Exchange – was it ever simple? What are Agile Services and why do we need them? How does this fit with Service Oriented Architecture (SOA)?
Part 2 – Technology (10 mins) Introducing OASIS Content Assembly Mechanism (CAM) Functional capabilities and business benefits But I have tools that already do all that!?! Who is using this and why?
Part 3 – Demonstration (30 mins) Tools overview Solving agility – Your very own XML example Value proposition Call to action/next steps
Q&A (10 min)
Copyright OASIS, 2005 / 2007
Presentation January 24th, 2007
Reston VA
INTRODUCTIONPart 1
Copyright OASIS, 2005 / 2007
Business Information Exchange – was it ever simple?
What are Agile Services and why do we need them?
How does this fit with Service Oriented Architecture (SOA)?
Copyright OASIS, 2005 / 2007
What did happen to FAX? FAX – the ultimate user solution
“Wet-ware” friendly interfacing Wide disparity in reproduction quality / resolution Partner “address” = telephone # Confirmation / Authentication Cheap hardware + simple plug-n-play use. 1980’s technology – FAX group 3 standard
Now - printable FAX forms + barcodes OCR scanning + digital imaging Weakness – double-entry / error checking
Enter simple XML – circa 1997 Internet-based technology Allows flexible and quick definition of
content Human friendly, machine processable Map arcane EDI formats to self-
describing XML layouts Pervasive standard and tools Promise: loose-coupling / agility
Copyright OASIS, 2005 / 2007
Secure web form data-entry Emergence of xhtml forms, Javascript,
XML and REST Ideal solution for large partners to reach
their downstream customers / service providers
OK for single solution partners, but tough on service centers
Weakness – double-entry / training / integration
Copyright OASIS, 2005 / 2007
Web service APIs + XML REST or WSDL based Examples – eBay and Amazon Sales support + virtual merchants Weaknesses –
Security Contextual information content Agility / versioning Integration / standards
Copyright OASIS, 2005 / 2007
XML today – COMPLEXITY! Use of namespaces, schemas and
object models – completely defeats human friendliness / simplicity
Programmer technology only Intractable to business users Complexity locks out agility + tight
coupling into backend integration code Brittle interfaces with low fault tolerance
= identical issues as with EDICopyright OASIS, 2005 / 2007
Presentation January 24th, 2007
Reston VA
INTRODUCTIONPart 1
Copyright OASIS, 2005 / 2007
Business Information Exchange – was it ever simple?
What are Agile Services and why do we need them?
How does this fit with Service Oriented Architecture (SOA)?
Copyright OASIS, 2005 / 2007
Agile Services are… Broad-based across industry domain Widely supported common functional set Use open transport interfaces to enable
participation from community Adaptive to local needs through robust
extension mechanisms Consistent with business partner and
legal best-practices Not based on technology lock-in
Copyright OASIS, 2005 / 2007
Information Agility Needs? Simple standards-based common base
business process transactions Common vocabulary across industry Sparse interchange formats (“SimplEDI”) Leverage simple XML techniques / tools Based on open rules methods Partner Role and Context aware Built-in versioning support
Why is this important? Creates long-term healthy market-place Open to complete range of service
suppliers Prevents customer lock-in and legacy
dependency Enables global trade reach Adaptive to new technology / changing
demands / emergency support
Copyright OASIS, 2005 / 2007
Presentation January 24th, 2007
Reston VA
INTRODUCTIONPart 1
Copyright OASIS, 2005 / 2007
Business Information Exchange – was it ever simple?
What are Agile Services and why do we need them?
How does this fit with Service Oriented Architecture (SOA)?
Copyright OASIS, 2005 / 2007
Service Oriented Architecture Loosely coupled, document-oriented
interaction model Provides simple messaging-based
interactions. Messages are more self-contained, lack object-oriented complexities and better accommodate asynchronous communications
Registry-centric - need for shared semantics, standards and processing logic
Enabling Context, Role and Intent critical
Example Architecture Model
Copyright OASIS, 2005 / 2007
Presentation January 24th, 2007
Reston VA
TECHNOLOGYPart 2
Copyright OASIS, 2005 / 2007
Introducing OASIS Content Assembly Mechanism (CAM) Functional capabilities and business benefits But I have tools that already do all that!?! Who is using this and why?
Copyright OASIS, 2005 / 2007
Copy Resources to runtime areaSource Code Management
Use Case Files
StylesheetsBaselineoutput
Runtime Directory
Use Case FilesUse Case
Files
BaselineoutputBaseline
output
Use Case Files
StylesheetsBaselineoutputUse Case
FilesUse Case Files
BaselineoutputBaseline
output
Schematron, & Template
DTD
Schematron, & Template
DTD
Copyright OASIS, 2005 / 2007
Summary of methodology System architect defines stylesheet modules Developer is assigned a module. Developer creates use case files. Use cases are reviewed Developer iteratively creates XSLT module Stylesheet and output files are reviewed Output is "baselined“
Copyright OASIS, 2005 / 2007
Benefits Scope is defined for developer Developer demonstrates understanding
immediately Use case files serve as communication tool Architect does not simply state constraints.
Constraints are enforced Regression test is built during development