Thread: Symphony-WorkManager: An implementation of (CommonJ) WorkManager under symphony API

1 about Commonj WorkManager
2 architectural design
3 implement details
4 program example
5 terms mentioned
6 Benefits and Potential Use Cases
7 project progress and plan
8 references
9 download code and doc for SymWorkManager version 1.0


================================================
First we give you some brief explain of Commonj WorkManager.
================================================


Why JSR237 WorkManager is a Market Need:

• Unmanaged multi-thread execution may either overload or underutilize system resources
• Loosely coupled JMS is complicated yet a unmanaged programming model
• Traditional J2EE application developers are limited to using single-thread execution

So here comes the:

JSR237 (CommonJ) WorkManager Programming Model

• Clients submit work items & data to WorkManager
• WorkManager schedules work items & data to a “thread” pool on an app server cluster
• Work items are executed under the "logically correct" execution context as if they are done by a thread pool in the same JVM as the client’s. The execution context usually includes user security info, session info, shared global data, and etc. It is propagated by a JSR237 implementation
• Clients can wait for the results asynchronously

================================================
Then let have a look of our Architectural Design
================================================


We want to use symphony java api to implement CommonJ WorkManager. Our workmanager name is SymWorkManager.

Our final target is to make users to use WorkManager to communicate with Symphony Clusters instead of using the Symphony API directly.

So that the user's commonj codes doesn't need to be modified at all to fit the SymWorkManager environment. The Symphony cluster is transparent to a commonj user.


CommonJ user ------------------- CommonJ Workmanager Interfaces
Symphony APIs ------------------- Platform Symphony Cluster



The work flow with Symphony WorkManager:





================================================
Here some implements details:
================================================

To implement the SymWorkmanager we must user symphony APIs to make commonj interfaces functioin properlly.

commonj.work.Work = Symphony task and input message
commonj.work.WorkManager = Symphony APIs and SSM
commonj.work.WorkItem = Symphony output message
commonj.work.Work.run() = app code called by Symphony service onInvoke() to process a WorkItem. It is transparent to app developers whether it is done in one or multiple JVMs
commonj.work.WorkManager.waitForAll() = a wrapper of Symphony fetchTaskOutput()
Execution context = similar to Symphony session context and common data


The sequence of SymWorkManager user program is as below:

Sequence Diagram





================================================
Program example
================================================


The SymWorkManager user can program codes just like the same under CommonJ WorkManager.
Here are some examples:




Users put their work logic in MyWork.class. The class will run on compute hosts of Symphony cluster to function user logic. Of course the MyWork class can be large or can work with other jar files. So the MyWork class file and other class files or jar files it use are userWork class files. They have to be predeployed onto the symphony cluster.



================================================
Terms mentioned:
================================================

CommonJ - BEA and IBM Joint Specifications.
WorkManager - A part of CommonJ.
Symphony Java API - Java API interacts with the platform of Symphony
Symphony WorkManager - Implementation of WorkManager with Symphony Java API

CommonJ is a series of specifications in order to provide programmers with simpler and more powerful ways of building portable server applications.

WorkManager is a part of the CommonJ specifications. It provides a simple API for application-server-supported concurrent execution of work items. This enables J2EE-based applications (including Servlets and EJBs) to schedule work items for concurrent execution, which will provide greater throughput and increased response time.

Symphony Java API : Symphony provide three APIs: C++, C# and Java.To communicating with Symphony Cluster, you must use the Symphony API. Because WorkManager is written in Java, we choose the Symphony Java API to implement the specification of WorkManager.

Symphony WorkManager: A concrete implementation of the interface of WorkManager of CommonJ under the Symphony API.




================================================
Benefits and Potential Use Cases
================================================

• Promote market awareness of Symphony functionalities and capabilities via supporting a simple, powerful, and industry standard programming model
• Provide managed execution and scheduling for concurrent and asynchronous Java/J2EE applications
• Grid-enable a Java/J2EE application less-intrusively or even without code change, if it follows JSR237 standard
• Can provide better work scheduling for existing clustered App Servers

================================================
Project progress and plan
================================================


We have now complete the drop 1 for the basic function of CommonJ WorkManager.

Symphony version: 3.1


Drop1:

• Provide Symphony API wrappers to support commonj workmanager, for applications to use a WorkManager to schedule WorkItems
• The client program uses only CommonJ workmanager APIs
• Multiple thread client program can uses different SymWorkManager concurrently.
• The userWork class files, which contains the logic of user program, must be predeployed onto the symphony cluster.

There are still something we want to improve about drop 1:

• User program must be predeployed onto the symphony cluster.
• The SymWorkManager haven't been integrate with j2ee environment. So the JNDI lookup part in the example above can not work. The user must initialize their own SymWorkManager instance.

So we are now working on these points. And our target for drop 2 is:
Drop2:

• dynamic transfer userWork class files onto the symphony cluster, the user program will work properlly without predeployment.
• use flags to control when to remove class files on compute hosts and whether to use dynamic transfer
• integerate SymWorkManager with j2ee enviroment

Progress fo drop2:

The basic functions of dynamic transfer class files and control flags are now working well. But there are still some synchronized problems on the service side. We are working on it.
We will also do some test on SymphonyDE 4.0 see if our Drop 1 fits.




================================================
References:
================================================


[1] CommonJ the BEA and IBM Joint Specifications.
http://dev2dev.bea.com/wlplatform/commonj/
[2] Commonj-TimerAndWorkManager-Specification-v1.1
http://dev2dev.bea.com/wlplatform/commonj/twm.html
[3] Symphony Developer’s Guide



================================================
download code and doc for SymWorkManager version 1.0
================================================

You can download all of our code and documentation in SymWorkManager v 1.0 here.

Symphony-WorkManager-Admin-Guide.doc
Symphony-WorkManager-Develop-Guide.doc
Symphony-WorkManager-Design.doc
symphony-workmanager-v1.0.zip
symphony work manager Test Report v1.0.zip

Thanks Simon. JS237 allows me to create work items in my Java program and not worry about thread management and how threads get executed. If I want more performance, I can can use your integration and connect my Java program to a Symphony system and add more compute nodes.

Can you post your drop 1 code and documentation? I would like to try it.

- Ajith