1 / 12

ebSOA Based on FERA Reference Model

ebSOA Based on FERA Reference Model. Vasco Drecun Collaborative Product Development Associates, LLC Goran Zugic ebXMLsoft Inc. Activities Inputs/outputs Flows Deliverables Dependencies Transactions Decisions Contracts Documents. Interfaces Security Messages Registries Repositories

krysten
Télécharger la présentation

ebSOA Based on FERA Reference Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ebSOA Based on FERA Reference Model Vasco DrecunCollaborative Product Development Associates, LLCGoran ZugicebXMLsoft Inc. April, 2005

  2. Activities • Inputs/outputs • Flows • Deliverables • Dependencies • Transactions • Decisions • Contracts • Documents • Interfaces • Security • Messages • Registries • Repositories • Content maps • Services • Events • Agents Patterns or use cases of information exchange Reference models SOA standards BPM FERA FERA reconciles BPM with SOA April, 2005

  3. Recognizing FERA configuration • Four process characteristics determine what FERA configuration is required • Human interaction determines the need for portal and collaborative services capabilities • Sign-on, authentication, plug-in services (meetings, calendars, chat, visualization, reporting, etc.) • Process administration determines the need for federation server and gateways • Security, protocols, content exchange formats, meta-data mapping, B2B process standards (RosettaNet, CPFR, …) • Process flow determines the need for event management • Alerts, Escalation, Messaging, Queries, Flow controller • Business logic reconciliation determines the need for agent framework • Synchronous vs. asynchronous reconciliation April, 2005

  4. Mapping to FERA components Reference model steps • Step1: Define content and context elements (static view – Federation Information Model (FIM) and Collaborative Process Information Model (CPIM)) • Step 2: Define choreography (dynamic view) – Collaborative Process Flow Information Model (CPFIM) and Agent Interface Information Model (AIIM) • Step 3: Determine FERA configuration. Four configurations are formally specified and they support all possible collaboration cases (patterns) examined so far. • Step 4: Document FERA capabilities and specific features required to support the choreography (requirements) • Step 5: Select applicable standards for the specified capabilities and features • Step 6: Produce a final document with all architectural requirements and components to support the pattern • Step 7: Deploy to ebSOA April, 2005

  5. FERA Functional Architecture Portal SOA Federation Federation Server Gateway Gateway Federated User Federated User Agent Framework CP Flow Federated System Federated System Plug-in Services Plug-in Services Collaborative Services April, 2005

  6. ebSOA Information Model • Federation Information Model (FIM) – Content and Context • FIM is an informational bridge between the public and private world. • Definition of federate profiles, business process specifications, collaboration protocols and agreements, security policies, etc. Information that supports public processes and documents of any type for both public and private processes. • Agent Interface Information Model defines types of agents, invocation rules and status control. • Collaborative Process Information Model (CPIM) • Supports complete CP context including all possible flows, participants and shared context elements like metrics, rules and joint events • The main CPIM entities are: CP Flows, Roles, Rules, Metrics and Clusters of Events • Collaborative Process Flow Information Model (CPFIM) • Supports definition of the possible flows of activities, decisions and events within the CP • The main CPFIM entities are: Activities, I/O-s, Events, Triggers, Decisions, Sequences, References, etc. April, 2005

  7. ebSOA Collaboration Semantics • ebSOA collaboration semantics in connection with ebSOA information model provides full dynamic collaboration support. • ebSOA collaboration semantics formally defines all necessary interfaces with methods/functions required for the collaboration data (ebSOA information model) manipulations and interactions between SOA Federation architectural components. SOA Federation is a central block of the ebSOA architecture with the following components which interfaces and methods/functions are already defined as a part of the ebSOA architectural specification: • Gateway • Portal • Plug-in Services • Security • SOA Federation (Federation Server, Agent Framework, CP Flow Controller and Collaborative Services) April, 2005

  8. ebSOA Collaboration Data and Semantics(Business Process Management) SOA Federation BPSS ebSOA Collaboration Semantics CPP Federation Registry CPA Process Flow Registry CPID ebSOA Collaboration Semantics April, 2005

  9. ebSOA Specifications • ebSOA Specifications include both static (SOA Federation Information Model) and dynamic view of the ebSOA architecture. The dynamic view support includes formalized ebSOA collaboration semantics of the SOA Federation internal collaboration and its interface for the external collaborations (federated systems) via Federation Server and Gateway. • The key components of the ebSOA Specifications include: • ebSOA Information Model that fully supports informational aspects of both external and internal collaborations • Collaboration semantics and interfaces for • Gateway • Portal • Plug-in Services • Security • SOA Federation (Federation Server, Agent Framework, CP Flow Controller and Collaborative Services) April, 2005

  10. ebSOA F E D E R A T E D S Y S T E M Modeling P O R T A L SOA Federation F E D E R A T I O N G A T E W A Y G Federation Server A Business Process Documentation creation and validation T Federation Manager Agent Interface Manager E W A Y Gateway Registry I N Federation Registry Security Provider T E R F Collaboration Protocol A C Agent Framework E F E D E R A T E D S Y S T E M P L U G I N S E R V I C E S Service Consumer CP Flow Controller Service Provider Collaborative Services April, 2005 Data Collection Analysis Reporting Other Built-In Services

  11. ebSOA Standard-Based Components Mapping • Gateway - Public processes ebXML BPSS for public process collaborations ebXML CPP/CPA - Business documents creation and validation OASIS CAM - Communication ebXML Messaging, SOAP with WS-Security, SMTP, JMS, etc. - Interface ebSOA Gateway Interface specification. - Registry Gateway Registry based on standard (ebXML Registry, UDDI) or proprietary implementation. • Portal Web server portal based on ebSOA Portal Interface specifications • Plug-in Services Web services based on ebSOA Plug-in Services Interface specification • Agent Framework Based on ebSOA Agent Framework Specification April, 2005

  12. ebSOA Standard-Based Components Mapping (cont.) • Federation Server - Federation Manager ebSOA Federation Manager Specification - Agent Interface Manager ebSOA Agent Interface Manager Specification - Federation Registry ebXML Registry Specifications (RIM and RS) - Security Provider ebSOA Security Provider Specification, XACML, SAML, etc. • Process Flow Registry Based on ebSOA Process Flow Registry Specification • Flow Controller, Event Manager, Activity Manager and Decision Manager Based on ebSOA Flow Controller, Event Manager, Activity Manager and Decision Manager Specifications. • Collaborative Services Third-party tools for data analysis, reporting, collaboration pattern analysis, data quality, etc. April, 2005

More Related