Recommended
More Related Content
Viewers also liked
Viewers also liked (12)
Similar to Rich Services: Composable chat
Similar to Rich Services: Composable chat (20)
More from bdemchak
More from bdemchak (20)
Recently uploaded
Recently uploaded (20)
Rich Services: Composable chat
- 1. Composable Chat A Rich Services Introduction Barry Demchak and Ingolf Krüger California Institute for Telecommunications and Information Technology (Calit2) for Space and Naval Warfare Systems (SPAWAR) July 19, 2007
- 2. Composable Chat • Complex Systems • DoD Chat Problem • Rich Services for Enterprise Chat – Systems of Systems – Service Oriented Architectures • Benefits of Rich Services (w/XMPP integration, too) • Rich Services Development • Case Studies • Questions
- 3. Common Problem: Complex Systems
- 4. Common Issues: Complex Systems • Integration of existing solutions • Flexibility in configuration and management • Legacy and emergent capabilities • Trust between domains • Security • Governance • Provisioning and policies • Scalability
- 5. Common Issues: Complex Systems • Disconnected operation • Degraded service • Low bandwidth • Point failures
- 6. The DoD’s Chat Problem • Many different chat-class systems have been deployed • Need – small set of standards and policies for federated Core Enterprise Services (CES) to address gaps and overlaps – accommodate both federal and coalition networks – accommodate local autonomy and global interoperability
- 7. The DoD’s Chat Problem (cont’d) • Enterprise Directory Services (white pages) • Enterprise presence awareness, IM, and chat • Enterprise authentication/authorization policies • Disconnected operation • Migration paths for current providers and consumers • Services must be manageable and monitorable • Integration of domain knowledge
- 8. Our (Partial) Solution System-of-Systems (SoS) + Service Oriented Architecture (SOA) = Rich Services
- 9. System-of-Systems Perspective • Military Applications – Command, Control, Computers, Communications, Information (C4I) – Intelligence, Surveillance, and Reconnaissance (ISR) • Information intensive systems integration – Development, integration, interoperability, optimization of systems for battlefield scenarios • National transportation system • Integrated military and space exploration
- 11. System-of-Systems Characterization • Maier’s Criteria for Systems-of-Systems – Operational Independence of Elements – Managerial Independence of Elements – Evolutionary Development – Emergent Behavior – Geographical Distribution • Others contributed by Purdue SoS – Interdisciplinary – Heterogeneity of Systems – System of Networks
- 12. Our (Partial) Solution System-of-Systems (SoS) + Service Oriented Architecture (SOA) = Rich Services
- 13. Service Oriented Architectures • Partitions system functions into logical, homogeneous modules • Emerging as a convenient solution to create low cost, loosely coupled, interoperable systems • Hides implementation details of the components that provide functionalities • Particularly suited to integration of COTS -- Ermagan, et al NOT NECESSARILY WEB SERVICES
- 14. Chat System Entities (existing) • Client • Server • Network • Gateway • Message system • Chat room • Presence system • Subscription database • Contact list database • Personal information database • Privacy list database • Message • Message confirmation • Subscription request • Subscription confirmation • Presence update message • Presence broadcast message • Contact list request • Contact list message • Personal info request • Personal info message • Privacy list request • Privacy list message Supports
- 15. Chat System Model Comm Link Logical Link Entity Legend
- 16. Chat Deployment Key Observation Interserver traffic consists of • Presence subscriptions • Presence updates • Messaging • Client information • etc
- 17. Chat System as SOA Hypothetical and simplified
- 18. Chat System as Rich Service
- 19. Rich Services in General Messenger Router/Interceptor Policy Service/Data Connector Messenger Router/Interceptor Failure Manager ... <<Rich Service>> S Service/Data Connector ... <<Rich Service>> S.n Service/Data Connector }<< Rich Infrastructure Services >> Encryption Service/Data Connector Logging Service/Data Connector Failure Manager Service/Data Connector ... Service/Data Connector S.1 Service/Data Connector S.2 Service/Data Connector }<< Rich Application Services >> S.n.2 Service/Data Connector S.n.m Service/Data Connector }<< Rich Application Services >> S.n.1 Service/Data Connector Service/Data Connector Logging Service/Data Connector Encryption Service/Data Connector Policy ... Service/Data Connector Service/Data Connector << Rich Infrastructure Services >> }
- 20. Chat System Benefiting from Rich Service Original Objectives – Enterprise Directory Services – Enterprise Presence Services – Enterprise authentication/ authorization – Disconnected operation – Migration paths for current providers and consumers – Manageable and monitorable – Integrate domain knowledge Additional Benefits – Leverages existing systems without modification – Move chat system to other venues – Opportunities for novel processing
- 21. Chat Systems in System-of-Systems Domain-dependent policies
- 22. Chat System with XMPP using Rich Services Integration Framework • Streaming XML • Authentication • Encryption – Client/server – Server/server • Addressing • Presence mgmt • List mgmt – Subscribe – Contacts – Blocks
- 23. Rich Service Development • Multistage concurrently • Logical vs Deployment Rich Services Virtual Network Rich Services RAS4 Services Service S1 Roles U1 U2 U3 U4 U5 Use Case Graph Concerns C1 C2 C3 C4 CC1 CC2CC3 Domain Model R1 R2 R3 R4 R5 R6 R1 R2 msg R3 CC1 CC2 Role Domain Model R1 R2 R3 R4 R5 R6 CC1 CC2 CC3 Router/Interceptor Messenger/Communicator RAS1 RAS2 CC1 CC4 CC5 Router/Interceptor Messenger/Communicator RAS5 RAS6RAS3 S / D S / D RIS: RIS: ServiceElicitationRichServiceArchitecture RAS7 System of Systems Topology H1 H2 H3 H5 H6 H7 H8 H9 H4 RAS1 RAS2 RAS3 RAS5 RAS6 RAS7 Infrastructure Mapping H1:RAS1 H2:RAS2 H3:CC1 H5:RAS2 H6:RAS5 H7:RAS7H8:RAS7 H9:RAS6 H4:RAS3 Optimization Implementation RAS1 RAS2 RAS3 RAS4 RAS5 RAS6 RAS7 CC1 CC2 CC3 CC4 CC5 Analysis Synthesis Analysis Identification Definition Consolidation Refinement Hierarchic composition Refinement Logical Model SystemArchitecture Definition Logical Architecture Loop Deployment Loop • Soup-to-Nuts • Incremental
- 24. Case Study – RESCUE • Perpetual data capture • Visualization of correlations • Opportunistic access • Access control
- 25. Case Study – ORION-CA • 10s of institutes • 1000s of researchers • 1000s of instruments • 100s of operators Global Scale Observatory Modeling Facility Research Laboratory S/D Connector S/D Connector S/D Connector Regional Cabled Observatory Observatory Service S/D Connector Identity Authentication Policy Accounting Logging S/D ConnectorS/D ConnectorS/D ConnectorS/D ConnectorS/D Connector Identity Authentication Policy Accounting Logging S/DS/DS/DS/DS/D Router / Interceptor and Messenger / Communicator Identity Logging Data Service S/D Router / Interceptor Messenger / Communicator ... Acquisition scheduler Science Instrument Web Service Matlab Processing Engine Power Monitor Instrument Service Repository S/D Connector Storage S/D Connector Scheduler S/D Connector Resource Repository S/D Connector State Management S/D Connector Router / Interceptor and Messenger / Communicator . . . INTERNET Service Rep. . . . State Mng. S/D S/D S/D
- 26. Summary • Rich Services – can be used as an integration architecture – provides guidance for understanding exploitable relationships between entities – provides framework for analysis and future growth • Rich Services Development Model – end-to-end (logicaldeployment, reqsphysical) – integrated, iterative, concurrent
- 27. Further Reading • [PDM III] DoD CIO. “PDM III Core Enterprise Services Finding and Recommendations Report”. September 2006. • [IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent. "Instant Messaging / Presence Protocol Requirements". RFC 2779, February 2000. • [XMPP-IM] Saint-Andre, P., Ed. "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence". RFC 3921, October 2004. • [XMPP-CORE] Saint-Andre, P. "Extensible Messaging and Presence Protocol (XMPP): Core". RFC 3920, October 2004. • [Prog Jabber] Adams, D.J. “Programming Jabber”. O’Reilly Media, Inc. January, 2002. • [Wikipedia] http://en.wikipedia.org/wiki/System_of_systems, March 2007. • [Maier] Maier, M.W. “Architecting Principals for Systems-of-Systems”. http:// www.infoed.com/Open/PAPERS/systems.htm, 1996. • [Purdue] https://engineering.purdue.edu/Engr/Research/Initiatives/SoS/ • [Ermagan] V. Ermagan, C. Farcas, E. Farcas, I. H. Krüger, and M. Menarini, “ A Service-Oriented Blueprint for COTS Integration: the Hidden Part of the Iceberg,” in Proceedings of the ICSE Second International Workshop on Incorporating COTS Software into Software Systems: Tools and Techniques (IWICSS'07), Minneapolis, MN, USA. IEEE Computer Society, May 2007, p. 10. • [Arrott] M. Arrott, B. Demchak, V. Ermagan, C. Farcas, E. Farcas, I. H. Krüger, and M. Menarini, “Rich Services: The Integration Piece of the SOA Puzzle,” in Proceedings of the IEEE International Conference on Web Services (ICWS), Salt Lake City, Utah, USA. Jul. 2007
- 28. Questions
- 29. Mobile Rich Services • Message rerouting as appropriate • Graceful degradation • Service provisioning via registries • Message persistence (supports disconnected operation)
Editor's Notes
- &lt;number&gt; Thank the host!
- 5 part slide 1st: A credit system … complex … taps capabilities of other systems Each system is autonomous … each has its own policies … each is maintained separately TOTAL SYSTEM = sum of parts + additional value added 2nd: DoD has assets … shipmates want to communicate with shipmates using a chat system – a single chat system picked by the sailors that will use it 3rd: Soldiers want to communicate with airmen … soldiers have their chat system, airmen have their own chat system 4th: Soldiers and sailors want to communicate with sailors … no chat system can be taken down … we want to leverage it 5th: We think of the enterprise chat system as a system of systems
- 2 part slide We’re combining SOS and SOA = RS
- Military has been doing SOS for years
- Everyday SOS Each system is autonomous … each has its own policies … each is maintained separately TOTAL SYSTEM = sum of parts + additional value added
- Maier wrote on SOS in 1996
- So, in addition to SOS … we use SOA What’s SOA??
- A definition from our group -- go over each line
- 3 part slide REVIEW OF CHAT SYSTEM – created and deployed in one step … no logical architecture … main entities support logical entities, which in turn support other logical entities. We need a model! … so we can factor these into the overall model 1st: Major entities … per deployment 2nd: In support of major entites 3rd: Further elaboration
- 2 part slide 1st: relationship of major entities 2nd: relationship to supported entities
- 3 part slide 1st: Deployment is different than logical model … we’ll come back to that later 2nd: Interserver traffic is messages 3rd: Key observation: MESSAGES … we’ll come back to that later, too
- 2 part slide 1st part: Client services cooperate to set presence and then propagate to other clients 2nd part: Services connected to a common message bus … a very flat view of a chat system
- 4 part slide 1st part: shows flat service collection communicating over message bus … what’s missing: interaction between chat systems and policy enforcement. Where would one deal with policies/logging/encryption/failuremanagement? 2nd part: shows infrastructure services … this is where the message passing between services is important … messages can be intercepted and preprocessed 3rd part: shows more realistic modeling … a client and a server. Note that the server is its own service composed of a service bus … note that infrastructure services can be different at different levels: LOCALITY 4th part: shows a fully composed rich service … note that one person’s gateway is another person’s service (see Server)
- The formal Rich Service diagram … just to see how *we* view it
- 2 Part Slide 1st: Start with Chat Engine in lower left Shows how an RS model could incorporate the services needed to meet the original objectives Note that Infrastructure services include *other* crosscutting processors … and could add even more without even touching the other services Basically, this shows how each of the Original Objectives can be met by modeling the chat engine as part of a Rich Service … thereby creating an Enhanced Chat System Talk about integration of domain knowledge: amounts to moving object references around, ala Cursor-on-Target and World of Warcraft 2nd: Additional benefits
- Shows an Enhanced Chat System as a component of a System of Chats Note that each level can have its own policies, definitions of infrastructure services, and administration Each chat system can be reconfigured independent of other systems Additionally, services (e.g., Directory Service) can be standalone, caches from a higher layer, or replications of a higher layer The point is that this model provides a framework for discussing and analyzing these issues Note that this is a *logical model* and may or may not correspond closely to a physical deployment … though it probably wouldn’t be far off
- Integrating XMPP Note the capabilities brought by XMPP In this model, XMPP is used for each of its capabilities, and is integrated with other services that it doesn’t already provide. Specifically, it displaces the certification authority and presence system in the Enhanced Chat model Moral: Rich Services is an integration architecture, weaving together existing and new services … composing them into a system of systems
- To be noted: Upper left: Use cases Lower right: Implementation Works well as multistage concurrent agile Calls out logical models and how they evolve to physical models
- Mass Casualty information system Service composed of other services
- Read all three top bullets
- Mass Casualty information system Service composed of other services