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.