Hey Mike...
Thanks for the input! See my comments inline...
Would you be interested in attending some of our public interop events with
your implementation? We plann on having some teleconference interops before
a Face 2 Face event as well.
Dave
-----Original Message-----
From: Mike Haller [mailto:mike.haller@attbi.com]
Sent: Friday, February 28, 2003 7:08 AM
To: ps@pwg.org
Subject: PS> Difficulty with AddDocumentByPost
I have an implementation of the job control interface circa last
November, and am finally getting around to updating it to something
more
modern (20030221), but I am finding the new AddDocumentByPost
difficult
to implement.
First, making the option mandatory will make it unnecessarily
difficult
to support an SMTP-bound SOAP implementation, since it forces an HTTP
server implementation.
<dave>
Which option in particular are you refering to?
</dave>
Second, allowing the lastDocument on this call means that heavy-duty
coupling must be done between the JCI implementation and whatever
implementation receives the SOAP calls, since the lastDocument = true
must effectively be deferred until after the post has successfully
completed. This implies that whatever receives the post must
communicate with the JCI implementation when it has been received
successfully. And of course, the JCI implementation already has to
know
all about whatever receives the post so that it can know how to create
a
new sink URL and go collect the data when it is done.
<dave>
Yep, this is very true, and I can't think of an easy way to decouple the JCI
implementation from whatever receives the post. I think inherently that
whatever receives the post needs to then add the data to the document that
was created in the original AddDocumentByPost SOAP call. - I've managed this
my placing a query parameter on the URL that is returned to the client as
follows:
We have a servlet that is listening on a particular path. The
AddDocumentByPost returns the following:
http://mypsiserver/axis/servlet/PSIPostServlet/urn:uuid:143832734-2340342-34
34-3
Basically, we encode the DocumentURI on the return path. This allows the
servlet that receives the post to make the association with the appropriate
internal JCI document as follows:
protected void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException
{
try
{
String documentURI = req.getPathInfo().substring(1);
// Find the appropriate document from our PSIDocument hash
PSIDocument doc = PSIDocument.getDocumentByURI(documentURI);
InputStream requestInputStream = req.getInputStream();
//Let the document object know about the input stream...
doc.post(requestInputStream);
// what do we return?
resp.setContentLength(0);
resp.getWriter().close();
}
catch (Exception e)
{
e.printStackTrace();
throw new ServletException(e); // ???
}
}
</dave>
It is also unclear what the implementation should do if the post fails
for some reason, or in what order the implementation can expect to
receive the posts. For example, it now seems the client could:
1. CreateJob
2. AddDocumentByPost last = false
3. AddDocumentByPost last = true
4. Post document 2
5. Post document 1
This makes the implementation difficult, without really seeming to buy
anything useful for the client.
<dave>
This is also true. Right now I have solved this by deferring processing of
the job untill all of the document data has been received. There are some
gating factors as to what allows a job to be processed:
lastDocument == true
AllDocumentDataReceived == true
</dave>
If the lastDocument flag were removed from the AddDocumentByPost call,
and if the additional requirement were made that the client could not
perform any additional AddDocumentByReference or AddDocumentByPost
calls
until either the post was complete, or a CancelDocument call were made
for the pending document, then the implementation would be much
simpler.
Then the example above would be:
1. CreateJob
2. AddDocumentByPost
3. Post document 1
4. AddDocumentByPost
5. Post document 2
6. AddDocumentByReference last = true reference = null
<dave>
I like the idea of adding the requirement that the data MUST be posted
directly after the AddDocumentByPost, and before any other AddDocumentBy*
methods are called. I'll add it to the latest rev of the spec, and see if
the working group approves.
I don't like overloading the AddDocumentByReference to indicate the "I'm
Done". Hopefully adding the interleaving requirement is sufficient for you
needs.
</dave>
Though I can't seem to find where AddDocumentByReference with a null
reference and attributes is actually allowed (it is, isn't it?) Maybe
it's not to late for a completeJob( jobURI ) call?
Mike Haller
This archive was generated by hypermail 2b29 : Fri Feb 28 2003 - 11:48:45 EST