Shahzad Bhatti Welcome to my ramblings and rants!

I am trying to use Enhydra Shark at work for implementing a workflow system, but I have been finding a lot of issues with it. Here are ten things that I found absolutely aweful about the Enhydra Shark:

1. All methods throw Exception as part of the signature instead of specific exceptions.
2. It uses constants instead of enums.
3. Many classes use public fields and underscore as part of the name, e.g.

                     public final class AppParameter {
                                    public String the_actual_name = null;
    

   it reminds me of a quote ‘You can write FORTRAN in any language”.

4. Every single Shark method requires transactions and many of the methods open and close several transactions per method, e.g. real code from another group using Shark:

               userTxn = getUserTransaction();
               userTxn.setTransactionTimeout(600);
               userTxn.begin();
                                                                                                 
                // Connect to the shark process repository
                SharkConnection connection = shark.getSharkConnection();
                connection.attachToHandle(executor.getSharkSessionHandle());
    
                WfProcess process = loadProcess(connection, userTxn);
                userTxn.commit();
    
                userTxn.begin();
                WfActivity activity = loadActivity(shark, userTxn, connection);
                userTxn.commit();
                                                                                                 
                userTxn.setTransactionTimeout(600);
                userTxn.begin();
                WMSessionHandle toolAgentSession = toolAgent.connect(connectionInfo);
                toolAgent.invokeApplication(session, toolAgentSession.getId(),
                            appInfo, toolInfo, null, processInstanceId, assignmentId,
                            parameters, appMode);
                connection.disconnect();
                userTxn.commit();
    

   Worst, some of the methods require both local and XA transactions.

5. It uses its own connection factory so I can’t use apache commons or other connection pool. It defines connection properties in several files, which don’t work as expected, e.g. some parameters are used for upper bound and other for lower bound.
6. It uses its own transaction factory so I can’t use declarative transactions using annotations or Spring. It is just not designed to work with any other framework.
7. It requires each JVM to connect with a unique engine name and another team had to generate that name on startup.
8. Its community does not answer questions (I never got response of my questions) and last activity on the mailing list was 10 months old.
9. It does not use latest XPDL 2.0, which has been released a few years ago.
10. Due to explicit connection management and transaction management several times per method, other groups using Shark found a lot of problems with multi-threading, scalability and reliability.

I like the frameworks or languages that follow “principle of least surprise”, on the other hand Shark follows “principle of voodoo magic” to get things working. In the end, I have not completely given up on Shark engine, but I have very low expectations.