From http://gigix.blogdriver.com/gigix/106028.html
Shark first impression -
I tried the ENHYDRA SHARK workflow engine, and I didn't know how to program it, only some skin impression.
Many huge - larger than OsWorkflow and Werkflow, the concept is very complete, and it is difficult to fully understand these concepts in a time. For OsWorkflow and WerkFlow, the only goal to be managed is the process instance, the status of the process instance, as for how to use the process instance, how to develop, all in workflow engines outer. SHARK management goals are much broad, such as the concept of user and usergroup, and users must have this role (ie group) to involve this process. I don't know if this will conflict with the unified user management platform.
Standard - Fully compliant with the WFMC reference model, and there is no additional extension, using XPDL as a workflow definition language. The standard is a good thing, but for some special processes, I am worried about its extension. For example, if an e-government often occurs a "disorder process" (as long as the leader is intercepted, can WFMC support? In addition, ENHYDRA provides a JAWE editor, which may be the best XPDL visualization editor.
Multi-Language Plug-in - For flows that need to be performed, Shark allows you to insert running units in multiple languages, including Java, JavaScript, Beanshell, Python, etc., believe that support for Groovy will be very simple. Our own workflow does not support automatic execution, OSWORKFLOW only supports simple beanshell (statements directly written in the configuration file).
Holding - The default persistence method is DODS, which is an O / R mapping of ENHYDRA. The original database is HSQL. I tried to migrate to mysql today, so I didn't know how this persistence mechanism was. Also provide the persistence of LDAP, and the transplantation of the persistence method does not know if it is difficult. I believe that the transplant is not too difficult to transplant based on o / r mapping.
Service interface - can be integrated as part of the application, or as an external service is integrated via RPC. Shark attaches great importance to the CORBA interface, which should be very helpful for integration of heterogeneous environments. There is also a point in performance: when intra-application integration, workflow engine and workflow instance will bring too much performance overhead? After all, it gives me a sense of heavyweight.
If you have time, you will continue to try to integrate your application first, then RPC integration is simple.
