Resource-oriented systems provide an interaction mechanism that is based on resources and simple operations that use HTTP methods.
The most representative model for a resource-oriented system is the REST model, combined for example with XML. The objects inside this model have a set of attributes that are related to their state. To invoke methods on the target system (communication mechanism), you must use the standard HTTP methods such as GET, POST, PUT, and so on, and follow some conventions.
You can consider the following when you develop plug-ins for resource-oriented systems.
If you use REST or only HTTP with XML, you get one or more XML schema files to be able to read and write messages. From these schemas, you can generate a set of classes that define the object model. This set of classes only defines the state of the objects because the operations are defined implicitly with the HTTP methods, for example, as defined in the vCloud Director plug-in, or explicitly with some specific XML messages, such as the Cisco UCSM plug-in.
You need to implement the communication mechanism in another set of classes. This set of classes defines a new object model that interacts with the original object model. The object model for the communication mechanism consists of objects and methods only.
You can expose both the original object model and the object model for the communication mechanism inside Orchestrator. This might add some complexity depending on how both object models are exposed, and on whether you are merging related objects from both sides (to simulate an object-oriented system) or keeping them separate.