…or should I build my service – vCO integration solution on top of plug-ins like HTTP-REST and SOAP? This is the million dollar question, especially after the public release of two general-pur...
See more...
…or should I build my service – vCO integration solution on top of plug-ins like HTTP-REST and SOAP? This is the million dollar question, especially after the public release of two general-purpose and powerful plug-ins like the HTTP-REST and SOAP plug-ins. The answer is not trivial but in short we could state that: If you act as a solution provider or partner and you want to offer to your customers an optimal orchestration solution for your service based on vCO, then you should create a new and specific plug-in for vCO. If you act as a vCO user and you want just to combine different 3rd party solutions inside your own vCO orchestration library, then you should use the existing plug-ins, it doesn’t really matter whether they are specific or general-purpose. So, what advantages will customers have with a dedicated vCO plug-in for your service? More flexibility With a general-purpose plug-in you have a limited set of building blocks (very basic workflows and actions, and few scripting objects) to build your own plug-in or library on top of it. And you’ll be able just to provide a more or less complex set of actions and workflows. On the other hand, when you create a new specific plug-in, you can start defining a rich set of scripting objects that are specific to your own domain, and a more complex (but concise) set of actions and workflows on top of them. In this way users will be able to choose the best way for them to use your plug-in, like using directly your higher-level workflow or using your fine-grained scripting objects instead. Better integration Related to the previous point, the set of workflows and actions included in your specific plug-in will fit exactly the functionalities that you want to provide to users. It means that you don’t need to include (nor implement!) any extra workflows or actions to workaround some of the limitations of the general-purpose plug-ins or to hide the complexity of using them internally all the time. Triggers and efficient long-running workflows When you develop a plug-in you can create and provide your own triggers to allow users to implement long-running workflows more efficiently. And of course you can provide also your own “waiting for trigger” workflow implementations, to help users to create efficient long-running workflows more easily. Optimization and performance When users have to create their own orchestration libraries with vCO plug-ins they are restricted, at the lower level, to the scripting box elements and the vCO’ scripting language. This Javascript-based language is good enough to work with the scripting objects from the plug-ins and to do few things more, otherwise you are quite limited or you need to do some kind of hack or complex workaround to make things work. But when you create plug-ins you use Java. It means that you have virtually no limitations. Your code will run directly compiled from the source files instead of being interpreted by the vCO’ scripting engine. Moreover, you can implement directly in your code some other optimizations that would be hard (or impossible) to do just from the scripting language. That’s why things that you can do in Java, it’s better to do them there rather than to do them manually inside scripting boxes. And if you are really motivated when developing plug-ins you can even try with other JVM compatible languages instead of Java Better configuration options Probably users will need to configure your plug-in somehow. And, ideally for them, this configuration should be consistent with the way other plug-ins are configured. When you create a plug-in from scratch you can decide what the best way to configure your plug-in is. You may offer a tab inside the vCO Web Configurator to configure all the settings, you may offer some special workflows for configuration purposes or you may even combine both ways if you need it. But if you are using a general-purpose plug-in, first you have to pre-configure it or to provide instructions to the user to configure it. And second, if your plug-in requires some extra configuration, more than the general-purpose plug-in, then you need to handle it manually with some scripting code. And you can provide just configuration workflows, no Web Configurator tab. Use of the inventory This point is especially important if you want to provide some kind of inventory (inside vCO Client’s Inventory tab) together with your plug-in. With this inventory, users can explore the objects that your plug-in exposes, to start workflows from them, and after that, when running workflows, to choose the appropriate input parameters very easily. And this is quite straightforward to achieve when you develop your own plug-in, but creating your own customized inventory is not possible from a general-purpose plug-in. Isolation Finally, this is another important aspect to be taken into consideration. If the solution you are providing is dependent on a general-purpose plug-in that you don’t control, users should be aware of it, because any change on the general-purpose plug-in (e.g. regular updates, accidental misconfiguration, etc.) could break your solution. And after that, possible fixes and patches won’t be dependent only on you but on other plug-ins and plug-in developers. But if your plug-in is isolated from the rest you have a much better control about what you are providing and how you are providing it, and usually at the end this is translated in a better user experience for the customers. But then, what are the general-purpose plug-ins useful for? For vCO users, to access to any 3rd party solution… Because a plug-in for a particular application is not available but the application exposes a SOAP or HTTP-REST API for example. Because a plug-in for a particular application is available but it is missing actions that the customer wants to automate. In this case a SOAP or HTTP-REST API could be used while waiting for a future release of the application plug-in that provides broader coverage. For solution providers and partners, to do some specific tests and to create prototypes and proof of concepts of new workflows and plug-ins. So, as you can see at the end, the general-purpose plug-ins are great for many things but they are not always silver bullets that you can use to integrate anything (e.g. your solution as a provider) in vCO. Especially when you are not creating a fully customized orchestration library but you want to provide a way (a plug-in) to customers for orchestrating your solution by using vCO.
