I uploaded a changed BES draft (we are now on version 33). This draft has
the freshly cleansed wsdl and xsd from Rich. As was agreed unanimously on
the telecon last week, I believe that this means that we are ready for
public comment.
-Mark
--
Mark Morgan
Research Scientist
Department of Computer Science
University of Virginia
http://www.cs.virginia.edu
mmm2a(a)virginia.edu
(434) 982-2047
Hi all,
I have a question about BES :
We implemented a plugin to our portal solution which let us run jobs to
any BES service (compatible with first version of this standard). So our
solution should work well with any service which conforms to this standard.
But we met some small problems although.
For our perspective we need to extract the job identifier - and here we
had to write suitable part of code for different BES services - why?
becuase ActivityIdentifier is a type of wsa:EndpointReferenceType and
here lies the problem. Every BES service use different tactics here. For
example when I tried BES service build upon LSF (platform.com) the job
id was added simply to the Address which is simply url with parameter
containing job ID. Other services always uses ReferenceParameters which
can be any xml data which is characteristic to the target underlying
system. So for every new BES service built on different middleware, job
managament service I had to write something like let say transition code
which extracts for me job id from different xml data. This way actually
I don't know if some new service will work well with my plugin.
This is a little confusing for me why in some common interface (let me
say that about BES) can have different job id notation. It is always
some string by the way which looks a little different for every
underlying system. So why it couldn't be also one xml schema concerning
job id?
Regards,
Dawid Szejnfeld, PSNC
