ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google

Mail Archive Home | shark List | January 2005 Index

<--  Date Index  --> <--  Thread Index  -->

RE: [shark] CVS Update - 050128

Hi Sasa

This all sounds great. I'm still happily using the official 1.0-1 release of Shark at the moment and will probably continue to do so until the next official release (1.1 ?) is made, as I'm using it in a production environment.

I'm particularly interested in using the query language API when it becomes available (...and I'm hoping it'll support limit/offset-style result sets...) so I'll definitely be looking to upgrade.

One thing that I'm a bit concerned about, though, are the DB-structure changes. Are there any plans to produce an upgrade tool that'll automatically migrate existing Shark 1.0 data to the new-style database (without any loss of data)? Such a thing will probably be vitally important for existing Shark users, many of whom will not be able to upgrade without it (I certainly couldn't afford to lose any of my processes, audit info, etc).

Thanks for any info - and it's always good to see the continuing development of Shark!


From: "Sasa Bojanic" <sasaboy@xxxxxxxxxxxxx>
Reply-To: shark@xxxxxxxxxxxxx
To: "Shark" <shark@xxxxxxxxxxxxx>
Subject: [shark] CVS Update - 050128
Date: Fri, 28 Jan 2005 18:45:06 +0100


Shark's CVS is just updated with many changes, improvements, and new features (some of them contributed and suggested by the people using shark). Thanks to all cotributions, discussions and useful sugestions!

Warning: to avoid possible problems, do a clean checkout, or just delete utils/dods folder, and do an update. After that use
standard procedure: "configure" and after that "make" or "make buildNoDoc"

- general
- shark implements the basic part of Wf-XML (Interface 4) for managing XPDLs (if you use new CVS JaWE version, you can connect to the engine, get the list of Process definitions, download XPDL, upload new XPDL or update existing, and all of that using standard
interface defined by WfMC)
- DB structure changed (many columns for storing various types of variables) - suggested by Ben Anderson - implementation of transaction caches (now you can make any kind of callback to shark from API implementations in the same thread
by the usage by the same transaction)
- new SMTP event audit impl. (sending mails on assignment event audit, and also calling default EventAuditManager (we need to write
documentation how to setup this)
- a great contribution by Dirk Hoffmann <dh.discuss@xxxxxx>, new ToolAgentLoader - now you are able to add new tool agents at runtime (the location where they need to exist is configurable - see Shark.conf -> ToolAgentPluginDir property - a great contribution by Abe Achkinazi <aachkinazi@xxxxxxxxxxxx>, new SchedulerToolAgent - it is a proxy for the call to other tool agents and opens a new Thread for their execution. It uses XPDL design with Automatic activity having Automatic start and Manual finish mode, and it is a general solution for long-running automatic activities. Abe also contributed great XPDL example for its
usage - test-Scheduler.xpdl.

- changes (extensions) to client APIs:
* AdminMisc (both POJO and CORBA) - additional methods for getting the time of process/activity creation, start(accept) and finish (some of you suggested this, but I can't find this post, so can't tell who did) * DeadlineAdmin (POJO) - additional method for optimized deadline checking (still not used in Admin apps, and CORBA
interface missing)
* ExecutionAdmin (POJO and partially CORBA) - additional methods for optimized deleting of finished processes, and for
deleting processes by its definition version (still not used in Admin apps)
* PackageAdmin - new method for getting Package content for any version of the Package

- changes to internal shark API's:
        * changes to InstancePersistence API:
- new method for retrieving processes (for their WfProcessMgr) by state - new method for retrieving activities (for their WfProcess) by state - new method for getting finished processes by their definition name and version - new attribute of ProcessPersistenceInterface for handling process creation time
        * Transaction API:
- new SharkInternalTransaction for the implementation of transaction caches (in fact, client always gets this
transaction, but he sees it as normal SharkTransaction)

- changes to kernel:
    * bug fix for update of deeply nested external package
* WfXXXIterators refactoring - they are now more efficient (further enhancement of those iterators along with API for creating query expressions coming next - we plan to transform query expressions directly to SQL statements) * refactoring of kernel's code due to the introduction of transaction caches

other changes/improvements/bug fixes
* BeanShellToolAgent and JavaScriptToolAgent now have additional context variables: "procInstId" (Id of the process that called tool agent), "assId" (Id of assignment for which tool agent is called - it is consisted of username and activity Id, and you can use AdminMisc to extract username and activity Id out of assignment Id) and "sharkTransaction" (shark's transaction ) which opens a new perspective of their usage (callbacks to Shark) - be careful not to define the XPDL variables having Ids as these new context
* encryption of the password storage, as suggested by Tom <tomc224@xxxxxxxxxx>
    * new utility in SharkTests for uploading XPDLs
* SQL scripts changed accordingly to DB structure changes, and to introduction of new indexes
    * shark architecture picture (colorful.html) is updated
* new version of AXIS jars and JaWE jars (with displaying AND/JOIN splits and various types of conditions differently), as well
as new concurrent.jar needed for the contributed SchedulerToolAgent
* SwingAdmin's now include Dirk Hoffmann's patch for multihead environment * Bug fix for AbstractToolAgent - the cache that was used for performance was not synchronized, and sometimes it caused
unnecessary exceptions in multithread environment

How to setup and test shark Wf-XML service?

* First approach - usage of service running on our local machine
WARNING: we can't guarantee that the server will always be online. Please don't misuse it!

1. you should have the latest JaWE's CVS version.
2. we have a Wf-XML (and ASAP) server running, and you can access it by JaWE or by public ASAP client
3. To use it from JaWE for getting definition list, downloading XPDL, uploading new XPDL or updating XPDL version, you should:
- go to File->WfXML (or press ALT-W)
- in "Registry service URL combo box for registry service URL enter http://www.prozone.co.yu:8080/axis/services/wfxmlRegistryBinding (or choose it from there when you already enter one), and press Connect button - now, you should have the list of process definitions, and you can press "Download" to import definition in JaWE. When you do that, you'll be informed about operation success or failure. Close the dialog, and you'll see the process definition(s) in JaWE - you can edit definition, and than again go to WfXML dialog, connect to server, select this definition from the table, and press
"Update". Now the engine should update existing definition
- if you want to add new definition (XPDL) to the engine, you can open XPDL from your file system, and than go to WfXML dialog, and
press "Upload" button

4. We have shark engine running with Shark Retailer demo, Shark Manufacturer demo process definitions (which are placed in two separate XPDLs comming with this Shark CVS version), and with a bunch of process definitions placed in the same XPDL (Shark and JaWE
will participate in next Wf-XML demo in Miami).

To use it from public ASAP client use following URLS for retailer and manufacturer processes (the similar usage is for other XPDL processes, but they mostly have manual activities, and won't be finished automatically)


Retailer factory

In addition to even/odd numbers meaning as for product_code value will determine which "daughter" service will be

if product_code < 100 no external service is called - internal manufacturer kicks in.

if 101 < product_code < 200 = Shark Manufacturer

if 301 < product_code < 400 = EasyASAP Manufacturer

if 401 < product_code < 500 = HandySoft Manufacturer

if 501 < product_code < 1000 = Fujitsu Manufacturer

if 1001 < product_code < 1200 = Shark Retailer

if (1301 < product_code < 1400 = EasyASAP Retailer

if 1401 < product_code < 1500 = HandySoft Retailer

if 1501 < product_code < 1600 = TIBCO Retailer

if 1601 < product_code = Fujutsu Retailer

Don't use values (201-300 and 1201-1300), service wouldn't work due to addressing problems inside our local network.

As we know Fujitsu services are also on-line and they work with shark, and for other we are not sure.

when you are filling up the Context data through public ASAP client, remove all the variable tags that you are not filling with a values (otherwise, in some cases, shark won't handle empty values properly, and also, by ASAP schema, it is not valid XML if you
leave empty values).

Second approach - set your machine to be Wf-XML (and ASAP) server:
use the instructions from last CVS update from 2nd of December last year. Instead of using "asapFactoryBinding" use


You receive this message as a subscriber of the shark@xxxxxxxxxxxxx mailing list.
To unsubscribe: mailto:shark-unsubscribe@xxxxxxxxxxxxx
For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.