Hi, Following is the architecture of the workflow support framework. This was initially planned for IS, but can be used across the platform.
*Workflow Request Handler* Build workflow requests and handle the callback requests. This interface can be implemented to be used for any event that need to trigger workflows. The request will have a uuid, and a set of parameters with their values. All these parameters are persisted and will be available at the callback handler by the time of response. However the requester can decide which of these parameters should be sent to the workflow executor and which should not. The callback handler will get the same request generated by the request builder, along with the status from the executor (approved, rejected or custom status). Based on the status the event can be completed or cancelled at the callback handler. *Workflow Executor* Execute the workflow engine and provide the response back along with the uuid. One implementation of this will be the BPEL/WS executor and will be available by default. However any other java implementation can also be used here. *WorkflowManager* Both RequestHandlers and Executors need to be registered here as OSGI services. In addition to that, WorkflowManager will - Decide which executor should be invoked for each request. - Persist the requests and maintain their state. - Receive responses from the executors and forward them to their respective callbackHandler. -- *Pulasthi Mahawithana* Software Engineer WSO2 Inc., http://wso2.com/ Mobile: +94-71-5179022 Blog: http://blog.pulasthi.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
