Appendicies


WELD Client/Database Communication Protocol


Interface Syntax

(Each line is terminated by "\n\r", including one additional line after the last line given).

Client:

PUT
<DB Identifier String>
<ClassName>
<ClassSpecificArguements * #ClassSpecificArguements> (each on its own line)

Server:

<XXX> (Three digit status code)
<UniqueObjectInteger (=0 if status failed)>

Client:

MODIFY
<DB Identifier String>
<ClassName>
<UniqueObjectInteger>
<ClassSpecificArguements * #ClassSpecificArguements> (each on its own line)

Server:

<XXX> (Three digit status code)

Client:

GETSTR
<DB Identifier String>
<ClassName>
<Location Identifier String>

Server:

<XXX> (Three digit status code)
<ClassName>
<ClassSpecificArguements * #ClassSpecificArguements> (each on its own line)
<UniqueObjectInteger>
<Int String # of Content Objects >
<Int String # of Container Objects >

Client:

GETID
<DB Identifier String>
<ClassName>
<IDString> (Integer String)

Server:

<XXX> (Three digit status code)
<ClassName>
<ClassSpecificArguements * #ClassSpecificArguements> (each on its own line)
<UniqueObjectInteger>
<Int String # of Content Objects >
<Int String # of Container Objects >

Client:

GETATT
<DB Identifier String>
<ClassName>
<UniqueObjectInteger>
<CONTAINER || CONTENTS>
<Int String of Attach # in list>

Server:

<XXX> (Three digit status code)
<ClassName>
<ClassSpecificArguements * #ClassSpecificArguements> (each on its own line)
<UniqueObjectInteger>
<Int String # of Content Objects >
<Int String # of Container Objects >

Client:

GETATTINFO
<DB Identifier String>
<ClassName
<UniqueObjectInteger
<CONTAINER || CONTENTS>
<Int String of Attach # in list>

Server:

<XXX (Three digit status code)
<ClassName
<UniqueObjectInteger

Client:

DELETE
<DB Identifier String>
<ClassName>
<IDString> (Integer String)

Server:

<XXX> (Three digit status code)

Client:

CONNECT
<DB Identifier String>
<ID For A> (Integer String)
<ID For B> (Integer String)

Server:

<XXX> (Three digit status code)

Client:

CONNECTNEW
<DB Identifier String>
<ID For A> (Integer String)
<ClassName for B>
<ClassSpecificArguements * #ClassSpecificArguements> (each on its own line)

Server:

<XXX> (Three digit status code)
<UniqueObjectInteger (for B)>

Client:

DISCONNECT
<DB Identifier String>
<ID For A> (Integer String)
<ID For B> (Integer String)

Server:

<XXX> (Three digit status code)

Client:

GETROOTDIR
<DB Identifier String>

Server:

<XXX> (Three digit status code)
<ClassName>
<ClassSpecificArguements * #ClassSpecificArguements> (each on its own line)
<UniqueObjectInteger>
<Int String # of Content Objects >
<Int String of "0" >

(returns first field of each content)

Client:

GETCONTEXT
<DB Identifier String>
<ClassName>
<IDString> (Integer String)

Server:

<XXX> (Three digit status code)
<ClassName>
<NumContents>
<ContentClassName> (each on its own line)
<Each Contents' first identifier> (each on its own line)
<Each Contents' UniqueObjectInteger> (each on its own line)


Versioning

Version strings are of the form A.B, where A&B are 32 bit unsigned integers.

Client:

GETVERID
<DB Identifier String>
<ClassName>
<IDString> (Integer String, ID of version object)
<VersionsString> (form A.B, "R", or "L")

Server:

<XXX> (Three digit status code)
<ClassName>
<ClassSpecificArguements * #ClassSpecificArguements> (each on its own line)
<UniqueObjectInteger>
<Int String # of Content Objects > (not valid/used)
<Int String # of Container Objects > (not valid/used)

Client:

PUTVER
<DB Identifier String>
<ClassName>
<IDString> (Integer String)
<Version Flag> ("P" for point (this single object) or "T" for tree rooted at this point. "R" appended to create a new release (incr A))
<ClassSpecificArguements * #ClassSpecificArguements> (each on its own line)

Server:

<XXX> (Three digit status code)
<UniqueObjectInteger (=0 if status failed)>
(if Flag is P - returns id of VO, if Flag is T returns the id of the top of the copy tree (now under a VO)).

(returns first field of each content)

Client:

VERGETCONTEXT
<DB Identifier String>
<ClassName>
<IDString> (Integer String)

Server:

<XXX> (Three digit status code)
<ClassName>
<NumContents>
<ContentClassName> (each on its own line)
<Each Contents' version string> (each on its own line)
<Each Contents' UniqueObjectInteger> (each on its own line)


(simple first cut)

Client:

QUERY
<DB Identifier String> (= "global" for global search)
<ClassName>
<Query Scope> ("G" for global, "C" for class, "D" for container/db)
<Search Index Type ("F" for fieldname, "I" for integer)
<Field Name/Index Number>
<IDString> (search String)

Server:

<XXX> (Three digit status code)
<NumContents>
<Each Found Object's Class Type> (each on its own line)
<Each Found Object's UniqueObjectInteger> (each on its own line)


Generators are tracked by the client, so that the server can stay as stateless as possible (in terms of connections).


Details


WELD Client/Server Communication Protocol


Interface Syntax

(Each line is terminated by "\n\r", including one additional line after the last line given). 

Called when a tool informs of the registry/data server of its availability.

(Resource) Client:

REG 
<DB Identifier String>
<ResourceName>
<ResourceMachineName>
<ResourcePortNumber>
<Number of Input Args for the tool> (in format #, or #-#, ie 1, 1-4)
<Number of Outputs> (in format #, or #-#, ie 1, 1-4)
<Possible input types> (string description)
<Possible output types> (string description)

Server:

<XXX> (Three digit status code)


Called when a tool informs of the registry/data server that it is no longer available.

(Resource) Client:

DEREG 
<DB Identifier String> (Is this necessary/reasonable???)
<ResourceName>
<ResourceMachineName>
<ResourcePortNumber>

Server:

<XXX> (Three digit status code)

Assumption: Tools will not stay down for an extended period of time without de-registering.

Tools can re-register, after a crash.

The triplet (name, server, port) should be unique.


Called when a client starts a tool flow manager and queries about the availability of network resources (for dynamic UI (menu bar) construction) from the registry/data server. 

Client:

QUERYREG 
<DB Identifier String> 

Server:

<XXX> (Three digit status code) 
<NumContents> 
<ResourceName> (the triplet of each available server will be listed)
<ResourceServerName>
<ResourcePortNumber>
...

(*Rationale: The tool/service name, server and port are the only essential information needed for a client to make a connection.) 

The data server needs to know where (which table) to look for the information.


Called when a client wants to get more data about a program at a "networked" server. 

Client:

RESLOOKUP 
<DB Identifier String>
<ResourceName>
<ResourceMachineName>
<ResourcePortNumber>

Server:

<XXX> (Three digit status code)

<TimesRun>
<TimesFailed>
<AvgRunTime> (seconds)
<TimeSinceStarted> (seconds)
<Last 10 results> (string of 10 chars : F/S/N (failed/success/not run yet)
<Number of input args>
<Number of outputs>
<List of workflow names> (strings, separated by characters)
<Input description field>
<Output description field>

The triplet (name, server, port) which "should" be unique.


Called when a proxy wants to input data about a program in the network worklist

Client:

RESUPDATE 
<DB Identifier String>
<ResourceName>
<ResourceMachineName>
<ResourcePortNumber>
<Workflow name>
<LastRun> (S for success, F for fail)
<LastRunTime> (integer #seconds)

Server:

<XXX> (Three digit status code)


Called when a client wants to execute a program at a "networked" server. 

Execute:

Client:

EXECUTE 
<DB Identifier String> 
<ToolName> 
<ParameterString> 
<Time interval of Heartbeats>  (in seconds, N for NO heartbeats)
<Number of Data Inputs> 
<Data>  (one for each number above, none if number is 0)

Server:

<XXX> (Three digit status code) 
<Data> 

The three digit status code should be "OK" to indicate that the tool has started running. Data is only meaningful if the status code is an error, at which point the tool has stopped. If there is no error, after it has started running, if heartbeats are on, it will return messages at heartbeat intervals, consisting of either :

<XXX> (Three digit status code) 

(where the status code is "OK" (alive, but not done)) or

<XXX> (Three digit status code) 
<Number of Data Outputs> 
<Size of Data Output>  (number of bytes, N if not available)
<Data> 

(where the status code is "FAIL" or "DONE") (The last two fields are repeated for the number of data outputs. Data of some sort must always be returned, even if (especially if!) the tool failed)




Workflow Protocol


Interface Syntax

(Each line is terminated by "\n\r", including one additional line after the last line given). 

Workflow Execution or Save

Called when a user wants to execute or save a workflow.

Client:

WFEXECUTE (WFSAVE)
<Name of Workflow> 
<e-mail address> 
    (Toolflow Information) 
<General Information>    (such as prioroty, max cost, etc.) 
<Number of tools> 
      (for each tool) 
<Tool Name> 
<Tool (Workflow) Number> 
<Tool Machine Name> 
<Tool Port Number> 
<Parameter of Tool> 
<Data for Tool> 
<User Comment> 
<Successors>  (each number separated by a space;
                          number of parameters to follow, then actual parameters
                          -1 represents no successors,
                          -2 indicates last tool)

Each successor will be followed by the output number of the current tool that is to be used in the following tool. Negative numbers, however, do not come in pairs. The number of parameters is = to [# of pairs] + [# of neg numbers].

The data for tool field specifies which tool inputs are actually used by the tool - basically, this indicates whether the parent tool generated data that the child needed, or whether it was just a condition that had to be met before the child could run. The format for this field is
<#args> <#arg * argument pairs>

where the argument pairs consist of <Node number> <Y/N>,and spaces separate the fields (as well as the pairs). The order of the pairs indicates the order in which the output of the parents should be sent to the child (tool server).

Server:

<XXX> (Three digit response code) 


Workflow Load

Called when a tool/client wants to load a workflow.. 

(Resource) Client:

WFLOAD 
<Name of Workflow> 

Server:

<XXX> (Three digit response code) 
<Toolflow Information> (Same as WFSAVE) 


Workflow Status

Called when a client queries the progress of a particular workflow with the Workflow Server. 

Client:

WFSTATUS 
<Name of Workflow> 

Server:

<OK code> 
<Tool status>
(code for each tool, separated by spac)
 N: not yet run, I: in-progress, D: Done, F: Failed)

<FAILED code> 
<Tool status>
<Information>

<DONE code> 
<Result> 


Workflow Close Session

Called when a toolflow client wants to close a toolflow session. 

Client:

WFCLOSE 
<Name of Workflow> 

Server:

<XXX> (Three digit status code) 


Workflow Tool Info

Gets the info for a tool from the proxy and/or database the Workflow Server. 

Client:

WFTOOLINFO 
<Tool Name> 
<Tool Machine Name> 
<Port Number> 

Server:

<XXX> (Three digit status code) 
<Time running in this session (only if session active)> 
<Number of times run (since registered)> 
<Number of times failed (since registered)> 
<Average run time>  (integer, seconds)
<Time since tool registered>  (integer, seconds)
<Status of last 10 jobs (string of 10 chars, F,S,or N (Fail, Success, N/A)> 
<Number of arguments that the tool takes>  (either # or #-#, ie 1, 1-4)
<Number of outputs>  (either # or #-#, ie 1, 1-4)
<List of other workflows using this tool> 
<List of possible input types> 
<List of possible output types> 

The last three arguments are all of the form:
#strings string#1 string#2 ...
(separator is the space character).
It should be noted that the largest (= most interesting flows) using the
specified tools will be the ones returned here.


Workflow Intermediate Tool Data

Gets the intermediate data for a tool (only can be called after a workflow has been executed). 

Client:

WFGETRESULT 
<Workflow Name> 
<Tool Number> 

Server:

<XXX> (Three digit status code) 
<Data>