copyright oasis, 2005 / 2007 slaying the complexity monster david webber chair oasis cam tc...

Copyright OASIS, 2005 / 2007

Slaying the

Complexity Monster

David WebberChair OASIS CAM TC

[email protected]

Presentation January 24th, 2007

Reston VA

Toward Agile Information Services

mailto:[email protected]

http://www.oracle.com/index.html

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)



Reston VA

INTRODUCTIONPart 1


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)?


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


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


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


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


Reston VA

INTRODUCTIONPart 1






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


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



Reston VA

INTRODUCTIONPart 1






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



Reston VA

TECHNOLOGYPart 2


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?


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


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“


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

copyright oasis, 2005 / 2007 slaying the complexity monster david webber chair oasis cam tc...

Documents