First read the Elevator pitch and One Minute Introduction.
PLASTIC is based on a very simple publish-subscribe architecture. Applications register themselves with a locally running "Plastic Hub" using one of the supported communication protocols. The Hub is then responsible for routing messages to one or more recipients.
Instructions are sent to other applications by means of messages, which may include a number of arguments and may also return a value. Although a set of core messages has been defined, application developers are free to extend PLASTIC by defining new messages. Contact the developer mailing list first to see if anyone has already defined a suitable message.
Plastic message strings are URIs, and all current messages have been chosen to be
IVORNs of the form
ivo://authId/key, to allow their future registration in
IVOA-standard registries. This would bring the
following benefits:
The client must create an object implementing the PlasticListener interface to receive incoming messages. This object is passed to the Hub at registration time.
The xml-rpc interface is suitable for other high-level languages that are blessed with an xml-rpc library such as Python or Perl. The xml-rpc interface is less strongly typed and involves a little more work on the client developer's part since their application must include an xml-rpc server through which they can receive messages from the Hub. The URL of this server is passed to the Hub at registration time.
Full details on the use of PLASTIC can be found in the Plastic Specification. A summary of the steps involved in using PLASTIC is: