Composable Chat Introduction
- 1. Composable Chat Orientation Barry Demchak and Ingolf Krueger California Institute for Telecommunications and Information Technology (Calit2) for Space and Naval Warfare Systems (SPAWAR) September 20, 2007
- 2. Introduction • Ingolf Krueger – Professor in Computer Science and Engineering Department, UC San Diego – Investigator at Calit2 • Barry Demchak – PhD student in CSE Department – Research Assistant • Calit2 Projects – RESCUE – Looking – OOI (Orion Cyberinfrastructure) – BioNet
- 3. Objectives • Study Disparate chat systems + Service Oriented Architecture (SOA) ------------------------------------------------------- = Interoperable chat systems • Manage complexity while adding and improving features
- 4. Project Focus • Centralized Administration of Chat – Authentication – Authorization – Presence Management – Domain-enriched Messaging
- 5. Approach • Data models of existing chat systems – IRC, XMPP, and SIMP – Create mindmaps UML class diagrams – Normalize class diagrams – Compare systems using normalized diagrams • Identify SOA options that make chat systems interoperable – Consider Rich Service pattern • Recommendations
- 6. Our Approach Mindmap Domain Model Normalize Identify Services Rich Services IRC, XMPP, SIMP, C-Chat f1(IRC) C-Chat f2(XMPP) C-Chat f3(SIMP) C-Chat Roles + Interactions Hierarchy: Conceptual + Deployment
- 7. Chat Deployment Key Observation Interserver traffic consists of • Presence subscriptions • Presence updates • Messaging • Client information • etc
- 8. Chat System as SOA Hypothetical and simplified
- 9. Chat System as Rich Service
- 10. 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
- 11. Chat Systems in System-of-Systems Domain-dependent policies
- 12. 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
- 13. Deliverables • Paper – Data Models and Analysis – SOA Options and Analysis – Recommendations • Presentations
- 14. Questions
Editor's Notes
- #2: <number> Thank the host!
- #8: 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
- #9: 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
- #10: 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)
- #11: 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
- #12: 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
- #13: 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