[jsdl-wg] Splitting Application

Donal K. Fellows donal.k.fellows at manchester.ac.uk
Wed Feb 9 05:58:34 CST 2005


This is the summary of the other part of Igor's proposal.

Basically, the proposal is that all elements inside Application should
be done as extensibility elements except for ApplicationType and
Description.

Then, the other current (v0.9 of the doc) elements inside Application
should be moved to another XML namespace that describes "executable"
type jobs (i.e. jobs that are fundamentally the running of an executable
even if that happens to be hidden away inside). Then, the other types of
jobs (particularly web-services invocations and SQL queries) that have
been mentioned involve other sets of extensibility elements inside.


For the "executable" elements, I suggest the following namespace:
   http://www.ggf.org/namespaces/2005/02/jsdl-executable.xsd

This should apply to the following elements:
   ApplicationName
   ApplicationVersion
   Argument
   Environment
   Error
   Executable
   Input
   Output
   ProcessCount
   TileSize
   WorkingDirectory

The interpretations of these elements laid out in section 4.2.2.8 (under
the 'executable' type) is correct and consistent. Other types that have
been suggested to me which fit under this banner include 'bat' and 'dll'
(both applicable to DOS/Win only; they're different types because they
both really need different invokation sequences - 'cmd.exe /c <blah>'
and 'rundll.exe <blah>' respectively - with these being details that it
is usually a good idea to abstract away.) We need to add a note that the
ApplicationType is *not* describing the format of the executable.
(Thanks to Chin Chee-Kai for raising these issues.)

Arguably, Limits should be done this way too, since they're only
meaningful to executable-type jobs.


For a "webService" invocation, the remaining body of the Application
element (apart from the ApplicationType and Description) should be a
normal SOAP envelope. The processing engine should use the JSDL Resource
section(s) to decide where to run hand off the invocation to and update
the SOAP header as appropriate (I think this is done by the wsa:To or
wsa:Via elements, but we'll need to get this checked by someone who
knows more than I do.) I don't know what to do about handling the
response from the invocation. ;^)


For a "sql" query, unless there is something already specified that we
can use, I suggest that the following extra elements be defined in the
namespace:
   http://www.ggf.org/namespaces/2005/02/jsdl-sql.xsd

Elements:
   Query
   Parameter
   Output
   OutputFormat

The Query element should contain an SQL query (formally as a string?).
Following on from what I wrote yesterday on a document-oriented schema,
it may also appear as a direct child of jsdl:JobDefinition, may be
imported, and may have ref and name attributes. The query should be
suitable for use as a Prepared Statement if any Parameter elements are
present. There should be one Query as a child of jsdl:Application.

The Parameter element may appear multiple times, and each represents a
single parameter to a prepared statement set up using the Query element.
Order matters (which is normal for these things it seems).

The Output and OutputFormat elements (should the format be an attribute
of the Output element?) specify where the result of the query is to go
and in what format. (Is there someone else's spec we can use here?)


I think that covers the summary of what's implied in Igor's proposal for
splitting up the Application element's contents. Note that what I've
written about SQL is not much more than a kite I'm flying. ;^)

Donal.





More information about the jsdl-wg mailing list