• Python 2.1 or above [ get Python ]
• Zolera Soap Infrastructure (ZSI), version 1.1 or 1.2 [ get ZSI ]

• pyGMA 0.1 sources
  

1. Install prerequisites
2. Download pyGMA from SourceForge into some directory, let's call it DIR, and let's call the tarfile pygma.tar.gz
3. cd to DIR
   
4. Untar and uncompress with gzip: gzip xvf pygma.tar.gz
5. This will make a directory called pyGMA-V.v, where V is the major version (0-9) and v is the minor version (1-9)
6. cd to pyGMA-V.v/test
7. run the tests: python all_test.py
8. If everything works OK, copy pyGMA-V.v to your Python lib/site-packages/ directory as "pyGMA", i.e., without the version numbers
9. That's it! Start using pyGMA
   
10.  Coming soon: distutils to automate steps 6-8!
    

The pyGMA is an implementation of the Grid Monitoring Architecture (GMA) Producer, Consumer, and Directory Service (or Registry) Web-Services SOAP interfaces in  Python ,a high-level object-oriented language. It uses the ZSI SOAP library to aid with serialization and deserialization of messages.

pyGMA is not a monitoring system; it is a framework that handles the SOAP communications between the monitoring components defined by the Global Grid Forum. It is up to the user of pyGMA to "fill in" the useful work that will be done in response to remote queries, subscriptions, and notifications. Therefore, the target "user" of pyGMA is really a developer that wants to connect existing or newly created monitoring components into a GMA-compatible framework.

A very minor exception to this is a simple "registry" component that has been provided. Although this component may be useful for testing or small-scale deployment, it is not intended to replace a distributed directory service.

The code and documentation is the responsibility of Dan Gunter, dkgunter@lbl.gov , a member of the Data-Intensive Distributed Computing Group in the Distributed Systems Department at Berkeley Lab (LBNL) .

The Grid Monitoring Architecure (GMA) is an abstraction of the essential characteristics needed for scalable high performance monitoring on a large distributed computational Grid. The GMA supports both a streaming publish/subscribe model, similar to several existing Event Service systems such as the CORBA Event Service , and a query/response model. For either model, producers or consumers that accept connections publish their existence in a directory service. Producers and consumers can then both use the directory service to locate parties which will act as a source or sink for the type(s) of performance data in which they are interested. The performance data itself is always sent from the producer to the consumer, but either a producer or a consumer may initiate the subscription or query to, respectively, the desired consumer or producer. For example , a producer locating and subscribing to a consumer could be used for an archiving service; and a consumer locating and subscribing to a producer could be used for a data visualization tool. In either case, communication of control messages and transfer of performance data occurs directly between a particular consumer/producer pair.

There are two types of communication endpoints: servers and proxies. A server is a communications endpoint that services requests, and a proxy is a local representation of that endpoint that transparently handles all the details of marshaling and unmarshaling the requests to the remote endpoint. For example, to communicate with a remote Producer server, you need a Producer proxy.

Another important object class is the event. An event represents semi-structured, timestamped data. Events have a name, and may contain zero or more fields and also zero or more containers (that themselves can contain fields or containers, etc.). Events are the atomic unit of monitoring data, and also can be used to describe the desired result in, for example, a query or subscribe operation.

The pyGMA servers, by default, will return a NotImplementedException for any of their public methods. To implement server functionality, for either the ProducerServer, ConsumerServer, or RegistryServer, follow these steps:

1. subclass the Server class, e.g., class MyServer(ProducerServer)
2. in the subclass implement do<Method> for the methods you wish implemented. See the appropriate server class for the proper method signatures.

The pyGMA proxies should "just work", once they are created and bound to a server. This always occurs at construction-time. Note also that the proxy tests the connection immediately by querying the server for supported features and caching the result.

• Building an Event object:

  from pyGMA import event
  e = event.Event("App")
  e.add(event.EventField("Program",value="GridFTP"))
  e.add(event.EventField("Bandwidth",value=100.0,units="Mb/s")
  

• Creating your own producer server:

  from pyGMA.producer import *
  class MyProducer(ProducerServer):
      free_ids = [4,1,3,5,7,8,9,23,]
      subscr_ids = {}
      def doSubscribe(self, event, url, sId, **kw):
          id = self.free_ids.pop()
          self.subscr_ids[id] = sId
          # Return (new) producer ID for subscr
          return id
  
      def doUnsubscribe(self,sid):
          if not self.subscr_ids.has_key(sid):
              raise core.ParameterError("Bad id %d" % sid)
          id = self.subscr_ids[sid]
          del self.subscr_ids[sid]
          self.free_ids.append(sid)
          return sid
  

• Running a producer proxy:

  from pyGMA.producer import *
  # Bind proxy to remote server
  pp = ProducerProxy(host='localhost')
  # Subscribe for event 'e'
  (sid,sid2) = pp.subscribe(e,"x-netlog://foo.bar.gov")