Transcript Mark Baker
Service Grids Workshop Mark Baker Distributed Systems Group University of Portsmouth http://dsg.port.ac.uk/~mab/ jGMA: An event-driven messaging service jGMA • jGMA, a Java-based implementation of the GGFs Grid Monitoring Architecture (GMA). – – – – General purpose distributed messaging system, Motivated because we wanted events moved around. API for non-blocking event driven messaging, Simulated blocking API built on-top of non-blocking API, – Default volatile registry, can use text file, relational or XML database for persistence, – Aimed at developers of tools and utilities; they need to build higher-level APIs for general purpose use. – For example can be used for logging, accounting, monitoring, error reporting, application steering. jGMA Features • • • • • • • • • • Compliant to the GMA specification, A small and simple API, Minimal number dependencies, Simple to install and configure, Use of Java technologies, Non-blocking and blocking events, LAN (Sockets) and WAN (HTTP) comms, Efficient and minimal impact on its hosts, Choice of registry – text/DBMS/XML. Firewall friendly! jGMA • First release (July 2004): – URL http://dsg.port.ac.uk/projects/jGMA/ • License – GNU • Support – Yes • SOA Model: – Basic core plumbing, will be adding a range of interfaces, in the first instance WS and then WSRF. jGMA Architecture Tomcat jGMA Registry Search/ Registration Tomcat Producer/ Consumer Servlet Producer/Consumer Message Path Producer/ Consumer Servlet Registration Search/ Registration Producer Consumer Producer Administrative Boundary jGMA Service Operations • gmaRegister(): – Description: Register a client. – IN: String suggestedName – RTN: String - non-blocking register, need to test for success. jGMA Service Operations • registryQuery(): – Description: Query the Registry. – IN: • String SQL. – RTN: • String URL. jGMA Service Operations • gmaUnRegister(): – Description: Un-register a client identified by the URL. – IN: • String URL. jGMA Service Operations • incomingGmaMessage(): – Receive a jGMA message in the form of a packed byte array - fired when an event (message) is received. – OUT: byte[] jGMA Service Operations • nonblockingReplyToMessage(): – Description: non-blocking reply to a message. – IN: • byte[] oldMessage, • String data jGMA Service Operations • nonblockingSendMessage(): – Description: Send a non-blocking message. – IN: • String to, • byte[] data. – RTN: int. What do you use to build your service? • Implemented draft specification: – GGF March 2000, updated Jan 2002, – GMA – loose specification, no API defined. – Many Variants: • Standalone - pyGMA, R-GMA, CODE, • Embedded – MDS(ish!), Autopilot, NWS… – PLUS • No defined API! So using own API, add 3 pts extra. • GMA long term life span! add 3 pts extra. • TOTAL: 9 pts. Service Dependencies • What else does your service depend on? – Nothing! – Optional XML/relational databases. • SQL now, Xquery later, for registry interaction. – GSI later. • What does your implementation depend on? – Java, Apache Tomcat (servlets). AAA & Security • Security: – Will use GSI. – Optional granularity: • • • • Combination of user and service X.509 certificates, ACLs, myProxy, HTTPS, – Being implemented! • Accounting/Logging: – Tomcat Logs, – Exception class, – User-level logging. • Monitoring: – Web Browser via PC servlets. – Adding stubs, prototype later this fall. Exploiting the Service Architecture • What features from your ‘plumbing’ do you use in your service? – Nothing at the moment. Service Activity • Multiple interaction or single user? – Handles events between registered producers and consumes. • Throughput: – Each PC Servlet can handle about ~1100 x 32 Kbytes messages per second. – Rate-feedback been added. • Typical data volume moved in/out: – Depends on what you do! Service Failure • Required Reliability – Failure semantics? • By default submit and forget, • Up to developers or users to implement higher-level functionality. • Required Persistence: – Use database for registries, – Jini-like Leasing, – Up to developer to implement other aspects. • Required Availability: – Potentially one of many! Required Service Management • Remote access to: – PC Servlet (via HTTP), • • • • • Track messages, Log messages, Messaging performance, Monitor messages, Message accounting. Issues • What is likely to happen to the GMA? • Need specification of the GMA API. • Others issues: – – – – – – Monitoring and debugging, Transactions, Test with other servlet containers, Impact of end-to-end security, Interaction with other services, Boot strapping.