Using OASIS standards for SOA development for eGovernment applications SOA CoP Technology Briefing MITRE, McLean, VA May 2006 David RR Webber

2 Unique eGovernment Challenges Business Perspective – meeting goals / needs Community of Practice – fostering open adoption Management – formal oversight and methods Accessibility – open platform, open system Security – certify participants, non-intrusively Agility – flexibility of interfaces, content, rules Performance – scalability, cost, re-use, maintenance

eBusiness and eGovernment Overview of Architecture and Components Needs

4 Registry SOA Functional Components Network Content Transport Security Manage Business Systems Workflow Payload Handling External Systems

5 External Systems Registry SOA Operational Details Network Content Transport Security Manage Business Systems Workflow Payload Handling Content Versions MoUs Business Rules Certificates Identity Role + Context Profiles Industry Semantics Partners EventsActions Errors Scripts Staged Synch Asynch Fire Wall Virus Check Receive Send Dispatch Errors Validation Business Rules

6 How can OASIS help? It’s all a bit overwhelming!!! Where to start? How to differentiate? How can I go from business requirements to technology realization? Divide the problem into layers! Tackle each layer, and ensure interaction between layers is consistent with open interfaces with known roles and context What can OASIS provide?

7 Formalizing the Business Needs Business-Centric Methodology Business Process Specification  ebBP / BPSS V2.0.3 External Processes Internal Processes  BPEL Internal machine level workflows / ERP integration Technology Architecture – FERA / ebSOA MoUs / CPAs Transaction interchanges and content Security – SSL, DSig, SAML

8 Business Agreement Languages (RINs) Choreography & Coordination Lang. (BPSS ) Collaboration Profile Agreement (CPA) Context Driven Information Exchanges (CAM) Semantic Registry Attaining SOA Through Component Layers

9 Interactive models Conventional models Changing the ”Just write code” paradigm Analysis Specification Design Coding Test Maintenance Developers Adaptation, integration Installation Use Needs Requirements Procurement Business Users Analysis Specification Design Coding Test Maintenance Developers Installation Use Needs Requirements Procurement Business Users

10 Operational Challenges Need to formulize and manage partner agreements both inside and outside enterprise Speed-up ability to integrate with partners by providing intuitive business-centric tools Provide common point of reference for partners to ensure consistent operational practices Facilitate re-use across enterprise by providing templates of proven solutions Provide open standards-based approach that can be accessed by implementation systems

11 1. Memorandum of Understanding - MoU Business Managers Meeting of the Minds Business Goals Define Scope Rough Timeline Creation / Best Practice Wizard OASIS components 2. Collaboration Protocol Agreements Operations Managers Precise Choreography Automated Messaging Parameters ebMS transport WSDL web services 3. On-line Registry Systems Administrators Manage operational use Provide automation access

12 Storing the Enterprise Artifacts Motivation Time People Specifications Schema Workflow Contract Directory Services Collaboration Partner Profiles - CPP Collaboration Partner Profiles - CPP Presentation Collaboration Partner Agreements- CPA Collaboration Partner Agreements- CPA Artifact relationships Content Assembly Mechanism - CAM Content Assembly Mechanism - CAM BP Specification Data/Codes Services/Functions Network XForms MSH/SOAP Source: BCM Lubash Pyramid Verbs Messages Rules Events Process Roles Transport Routing, Packaging Transport Routing, Packaging Nouns Core Components Core Components WSDL

13 Information Exchange Integration requirements Outward facing messaging systems Formal agreement profiles for business participants Business process workflow definitions Information exchange rules Registry to hold agreements, definitions, scripts… Internal integration routing and dispatch methods User interfacing for entry and control

14 SOA Exchange Design Goals Automated registration of participants Ability to self-certify exchange transactions Version control and ability to approve partners Centralized registry for participant management Declared and shared business rule scripting Integration through messaging services Backend application integration services Uses open public specifications and open source

15 Commercial Examples Today StrengthsWeaknesses Market presence Content and Services Agility Rapid deployment Simplicity of Content Transient value-less content Legal position Degrade content at peak times Weak Partner model Weak Security model Control of content use OpportunitiesThreats Expand markets Expand partners Expand content and services Capacity Saturation Service Degradation Competitive Abuse of Information Amazon.com & eBay.com

16 Leveraging Open Standards Combining best-of-breed solution with both ebXML and Web services working together Expose synchronous and asynchronous interfacing to control content access Open source solution components to allow unrestricted integration by partners Foundation of ebXML formal interchange model Leveraging loose coupling of web services Industry best-practices and lessons learned (who has solved similar needs?)

XML Technology Detail Some Components, Specifications and Implementation

18 Linkage Between Messaging and CPA Messaging envelope contains:  Sender name  Service / Action names  Sender CPA id value  Receiver CPA id value  Optional certificate CPA validation contains:  CPA id lookup to registry  Verifies sender  Verifies valid Service / Action pairs for this partner  Coupling from Service / Action to transaction validation  Coupling from Service / Action to backend delivery  Verify certificate

19 Role of the Registry for SOA Trading partner management  Registration of trading partners with Agency Authorization to do e-business with Agency Authentication integrated with Backend Applications (single sign-on)  Simplified management of CPAs / SSL certificates  Self service management of providers capabilities & certifications Metadata management  All XML schemas for transactions  All trading partner capabilities (including all of agency services)  Definition of data elements in each transaction  Instructions, documentation, and other Version management of objects in registry

Opportunity Summary Lessons learned; Technology Metrics

21 Lessons Learned Providing self-service facilities is key to rapid adoption Infrastructure exists today off-the-shelf to create pre-built templates for industry domains Using open specifications allows integration into wide range of environments Open source solutions allows partners to readily obtain technology Use of partner id concept to manage partners and versioning interchanges

22 Technology Metrics Create infrastructure that can support large communities via registry-managed control mechanisms  Provide simple integration for external partners by providing open source solutions as base-line  Supports commercial tools that implement ebXML and web services  Built-in methods that allow centralized control over rules, versions, and delivery routing  Reasonable security without being overly inhibiting to adoption  Complete integrated audit trail logging Using existing specifications and toolsets  Proven technology with wide adoption and reference deployments

23 Opportunities Provide infrastructure for application across a broad cross section of related agency and departmental areas:  HHS - Cancer Research Centers  CDC – Emergency Alerting systems  Navy – Medical Services coordination  FEMA – Emergency supply chain delivery  DHS – Intra-agency information sharing  EPA – External regulatory reporting  NSF – National Science Foundation Grants

Q & A Discussion Nortel Government Solutions For more information Visit our Website:

25 Project Resources NIH eRA Project site – NIH Grants site Commons online site – Grants.gov online site –

26 Technology Resources