1 / 20

Service Grids Workshop

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,

jeroen
Download Presentation

Service Grids Workshop

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. Service Grids Workshop Mark Baker Distributed Systems Group University of Portsmouth http://dsg.port.ac.uk/~mab/

  2. jGMA: An event-driven messaging service

  3. 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.

  4. 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!

  5. 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.

  6. jGMA Architecture

  7. jGMA Service Operations • gmaRegister(): • Description: Register a client. • IN: String suggestedName • RTN: String - non-blocking register, need to test for success.

  8. jGMA Service Operations • registryQuery(): • Description: Query the Registry. • IN: • String SQL. • RTN: • String URL.

  9. jGMA Service Operations • gmaUnRegister(): • Description: Un-register a client identified by the URL. • IN: • String URL.

  10. 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[]

  11. jGMA Service Operations • nonblockingReplyToMessage(): • Description: non-blocking reply to a message. • IN: • byte[] oldMessage, • String data

  12. jGMA Service Operations • nonblockingSendMessage(): • Description: Send a non-blocking message. • IN: • String to, • byte[] data. • RTN: int.

  13. 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.

  14. 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).

  15. 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.

  16. Exploiting the Service Architecture • What features from your ‘plumbing’ do you use in your service? • Nothing at the moment.

  17. 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!

  18. 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!

  19. Required Service Management • Remote access to: • PC Servlet (via HTTP), • Track messages, • Log messages, • Messaging performance, • Monitor messages, • Message accounting.

  20. 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.

More Related