120 likes | 135 Views
CEE and Grid Architectures. Geoffrey Fox September 15 2004. Collaborative Communication Tools (Chat, Whiteboard, Audio Conference, Application Sharing, Instant Messaging). Object /Document Management. Enterprise Builder. Forms Builder. Reasoning Mechanisms. Workflow, Product &
E N D
CEE and Grid Architectures Geoffrey Fox September 15 2004
Collaborative Communication Tools (Chat, Whiteboard, Audio Conference, Application Sharing, Instant Messaging) Object /Document Management Enterprise Builder Forms Builder Reasoning Mechanisms Workflow, Product & Process Modeling (Drag & Drop Development, Manage Enterprise Resources, Distributed Execution) Decision Support (Enterprise Object Modeling, Intelligent Agents) Forms Creation Object Config Control K2 -- Knowledge Kinetics An Instance of CEE Human to Human Communications Workflow Builder
Transforming to a Grid Architecture (Layer 4) AFRL CEE (Layer 3) (Layer 5) (Layer 6) (Layer 2) (Layer 1) Community Grid Architecture is only loosely defined
Overall Comments I • System Support Services is roughly Hosting environment in Grid parlance • Uncertain as web services don’t use this routinely and one has several important components • Basic Linux or equivalent single (possibly parallel but not distributed) computer operating system • Basic Axis (Java/Linux) or WSE (.NET) Web service Environment • Handlers (plug-ins) for Axis and WSE to handle core capabilities interpreting SOAP header – Security, Reliable Messaging, Transport • a) and b) above are probably what is usually called hosting environment
Messaging Process SOAPBody Header Process SOAPHeader Body Overall Comments II • Communication Services are messaging (transport protocol, routing) using SOAP protocol Service itself Serviceitself Customizable HandlerChain processesSOAP Header Invoke Other Services from Header or Body
Overall Comments III • Modeling and Simulation Support • Compute Grid using Globus, Condor or Gateway • Visualization Grid • GIS (Geographical Information System) Grid • Data repositories and sensors linked by GridFTP or high speed streaming • Data resources can be described by OGSA-DAI and its variant WS-DAI (Web Service Data Access and Integration) • Other services for caching, file access and management • This includes CEE Real-time services
Service1 Service3 Service2 Service4 Overall Comments IV • Interfaces are defined in WSDL using Semantic Grid for intelligent reasoning • 3-level programming model • Conventional languages (Java, C++) for service itself processing SOAP body • Semantic Web to reason about interfaces and their linkage • Workflow to link services together Semantic level Workflow links Services and is informed by the Semantic level
Layers of Onion Application (level 1 Programming) Application Semantics (Metadata, Ontology) Level 2 “Programming” Systems Metadata (Context, State) Basic WS-* Infrastructure Web Service 1 WS 2 WS 3 WS 4 Workflow (level 3) Programming All capabilities are built as Web Services with this structure showing a 3 level programming model
Overall Comments IV • Collaboration and Security are core Grid and Web Service technology • Security has a wide range of requirements – all of which can probably be supported by Web Service Security eventually • Some scenarios significantly easier than others • Asynchronous Collaboration or shared resources is traditional Grid technology • Synchronous Collaboration is supported by GlobalMMCS and XGSP • GIS Grid and GlobalMMCS a good start to support real time crisis support • Similar in style to TangoInteractive at Syracuse
Overall Comments VI • Grid workflow implements both composition (service linkage) and traditional business or process workflow • Intelligent Agents are services possibly using semantic web technologies at the application (processing SOAP body) level • Use of MVC (Model View Control) architecture in CEE completely consistent with Grids and Web Services • Use like KK, portlet architecture integrated into a portal • OGCE has many Grid Service portlets • Jetspeed, uportal, GridSphere debate in community
Overall Comments VII • Message-based Services naturally support “state change architecture” as Web services change their state on receipt of messages • They render (display) their state through user-facing ports • This leads to shared input and output port Web Service Collaboration models • Use NaradaBrokering to archive messages so supporting fault tolerant services and management of service updates • Use WS-Notification/Eventing to support notification of changes as those found by ECOM • OM in ECOM becomes Resource?
Next Steps • Review Architecture Analysis and mappings of CEE, KK to Grid concepts • Define the Services in CEE • Make them “simple services” i.e. as small as possible subject to constraint that communication overhead with Internet latency is acceptable • Transformations, Product Models, Process Models become services • Identify useful external services • Define the Interfaces in WSDL • Evolution v Revolution • Examine implementation of core capabilities – Security, workflow, data and computing capabilities • Interesting research on asynchronous collaboration and state change architecture, integration of service and product (process) workflow.