Hi,
One question first, the object that you want to monitor the state from, is it available as a plug-in scripting object and/or through the plug-in inventory? (And could you provide some context about your plug-in, plug-in inventory/objects and so on?)
- If not, you can simply implement the monitoring logic from the plug-in with a simple (small) thread pool or java.util.concurrent.Executor and a queue of objects to monitor. This is the recommended way, more efficient than having or starting independent threads for each object to monitor.
- If yes, the things get more interesting...
The "standard" procedure to handle that "object monitoring" has few steps (and it's better and easier if you use the Spring flavour of the plug-in and the Plug-in SDK):
1. You have to expose a plug-in scripting object method that creates a vCO trigger instance (ch.dunes.vso.sdk.api.PluginTrigger) from the object that you want to monitor. That trigger basically will contain a set of properties that you can set (e.g. the object id) and get later on when you need to get the actual object to check its state. The SDK provided service com.vmware.o11n.plugin.sdk.spring.watch.WatchRequestService (which you can autowire) and the helper collection com.vmware.o11n.plugin.sdk.spring.watch.WatchRequestCollection make the things easier.
2. You have to create a workflow (distributable with your plug-in) that uses the method from step 1, passes the created trigger to a "Waiting event" element and after that process the result of the trigger. The "Waiting event" element will take the trigger and pass it to vCO, that will wrap the trigger within a watcher (ch.dunes.vso.sdk.api.PluginWatcher) and send it back to the plug-in to be monitored by your plug-in's object monitoring logic. At run time, the workflow will pause in the "Waiting event" element until (depends on your logic) the object reaches the desired state or the trigger fails (e.g. connection errors, timeouts, etc.). Typically this type of workflow looks like:
3. You have to create, back at development time, an implementation for the com.vmware.o11n.plugin.sdk.spring.watch.WatchRequestListener interface. Through this interface vCO will notify the plug-in that there's a new trigger/watcher to take care of when someone runs your workflow from step 2. Basically, your method implementation for watchRequestAdded(WatchRequest) should extract the properties that you set in step 1, and use them to create a "task" (e.g. ending up on some kind of java.lang.Runnable implementation) which will be enqueued on your own list of tasks (e.g. using a java.util.concurrent.LinkedBlockingQueue) to be monitored with your preferred monitoring process (e.g. through a self-managed thread pool or directly using a java.util.concurrent.Executor). And your method implementation for watchRequestCanceledOrExpired(WatchRequest) should stop or cancel the task which is monitoring that particular object and remove it from the queue (this method is invoked for example when the user cancels the workflow which is waiting in the "Waiting event" element or there is some timeout). Again, for that WatchRequestListener interface implementation you can use the autowired WatchRequestService and the helper WatchRequestCollection.
And basically that's the main idea. As simple as that 
Finally, you can take a look at the guide "Developing plugins with VMware vCenter Orchestrator" from https://developercenter.vmware.com/web/sdk/55/vco and check the sections about Triggers and Watchers. The guide is a little bit outdated but the concepts and many of the sample still apply.
I hope it helps.
Sergio