Hey Harry...
I believe that the polling scenario is indeed the correct model. For this
particular method, we may not have it exactly right. We could overload the
JobID == 0 to mean that no job is available, but that doesn't quite feel
right.
Throwing an exception in this case is really our way of informing the client
(targetdevice) that no job is available for it yet.
Dave
Pseudo code:
Boolean bJobAvailable = false;
String JobID = "";
while (!bJobAvailable)
{
try
{
JobID =
PrintService.TargetDeviceSupportInterface.GetNextJob("myTargetDeviceIdentifi
er");
bJobAvailable = true;
}
catch (Exception e)
{
if (e == InvalidTargetDeviceIdentifier)
{
exit(InvalidTargetDeviceIdentifier);
}
elseif (e == TargetDeviceNotSupported)
{
exit(TargetDeviceNotSupported);
}
elseif (e == NoJobAvaliable)
{
// OK, keep polling
}
}
}
// Now we have a JobID, continue processing...
-----Original Message-----
From: Harry Lewis [mailto:harryl@us.ibm.com]
Sent: Thursday, September 19, 2002 1:48 PM
To: HALL,DAVID (HP-Vancouver,ex1)
Cc: BERKEMA,ALAN C (HP-Roseville,ex1); HALL,DAVID (HP-Vancouver,ex1);
ps@pwg.org
Subject: RE: Throwing exceptions
OK, thanks for that clarification. Related question...
In the TargetDeviceSupportInterface the operation GetNextJob "throws and
exception" if no job is available for the target device. I assume, then,
this is a SOAP "fault"? If so, is this really what we want? The design is
polling from target device to print service. In this case won't "no job
available" be the more likely case? Or, are we suggesting (via the
scenarios) that the target device isn't expected to poll unless having been
asked to out of band by a client (implying there SHOULD be a job present...
thus the "fault")?
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"HALL,DAVID (HP-Vancouver,ex1)" <dhall@hp.com>
09/19/2002 10:33 AM
To: Harry Lewis/Boulder/IBM@IBMUS, "HALL,DAVID
(HP-Vancouver,ex1)" <dhall@hp.com>
cc: ps@pwg.org, "BERKEMA,ALAN C (HP-Roseville,ex1)"
<alan_berkema@hp.com>
Subject: RE: Throwing exceptions
We are rapidly approaching a working PSI prototype that will be able to
"throw exceptions" from the method calls. They are known as "soap
faults"...
Our current methods don't "throw exceptions" in the XML string parameters
that are returned, it was an unfortunate naming of the return paramater -
"ExceptionAttributes" that is now named "UnsupportedAttributes". Returning
"UnsupportedAttributes" does not mean that an error has occured, rather that
some requested attributes are not supported by the service.
We will be throwing "faults" from the soap calls...
Hopefully this is clearer now..
:)
Dave
-----Original Message-----
From: Harry Lewis [mailto:harryl@us.ibm.com]
Sent: Thursday, September 19, 2002 9:22 AM
To: HALL,DAVID (HP-Vancouver,ex1)
Cc: ps@pwg.org; alan_berkema@hp.com
Subject: Throwing exceptions
How to throw an exception form a SOAP method.
I see this in the spec as a question ... "DHall - define exactly how to
throw an exception from a SOAP method" section 5.3.1.
Our current definition packages exceptions as a multi XML string parm set in
the return. Is this our conscious resolution to PSI exceptions? Have we
considered throwing exceptions, independently, across the web services
interface?
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
This archive was generated by hypermail 2b29 : Thu Sep 19 2002 - 17:12:48 EDT