You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Wouter Cloetens <wc...@raleigh.ibm.com> on 2000/08/03 08:07:10 UTC
Re: Java Sevlet Implementation - Attachment
On Thu, 3 Aug 2000 10:52:17 -0500, Steven J. McDowall wrote:
>I have finished a PRELIMINARY Servlet version of rpcrouter.jsp.
Good work. I'm especially happy with the Unicode support. :-)
Hmm, why would you support the GET method in it? That can't deliver a SOAP payload.
Only POST and PUT have content...
Another problem with the JSP version that's still in the servlet version, is that the try block
to catch SOAPExceptions and then return SOAP faults, does not extend over the part at
the bottom that builds the response. That part can also throw SOAPExceptions, which will
let the servlet engine send some HTML error page it generates itself. Even the
SOAPException catch block doesn't always return a valid SOAP error response (just a
message or a stack trace sometimes).
bfn, Wouter
--
http://www.workspot.net/~zombie/soap/
My opinions are irrelevant. They will be assimilated by my employer.
Re: PROPOSAL on scopes (was: Re: Java Sevlet Implementation -
Attachment)
Posted by Blaine Horrocks <bl...@cp.net>.
While from an rpc perspective the application, session and request semantics
are pretty clear you could make a case for the pages semantics also. The
real problem is that the semantics are different. The first three express
semantics relative to state involving the user and the implementation of the
behaviour (i.e. how much state the implementation can hold across requests).
Page semantics otoh, reflect semantics between the user, implementation, and
also the resource identified by the url, making it confusing.
Really this is just another aspect of whether the soap spec should be tied to
http as a transport. Now, according to the present spec if you have the header
=> SOAPAction: "" <= in your http url indicates the intent (target?) of the
rpc. Naturally this would be a page in html-land. It would almost require
the 'page' lifecycle if you were intending to share resource state over
multiple users unless you were willing to reread it from persistent storage for
each request. Rereading it is of course the accepted way that TP monitors
achieve load balancing. <g>
Now it would be nice to have some way to target various resources using RPC as
well as through a browser. If you think MVC, or just MV in this case, the
resource becomes the model, and the choice of representation would depend on
whether you accessed by requestiong a soap rpc or just a page view. Which
I think may have been the original intent of the SOAPAction binding.
Apache-soap uses the method name namespace urn as the "target" of the rpc,
which is actually wrong wrt the spec. The spec states (section 7) that "For
example, for HTTP the request URI indicates the resource that the invocation is
being made against". If this is really true then 'page' sematics can make
sense.
Long and the short of it?
- Page lifecycle does make sense from the spec but we probably don't want to
support it because it implies maintaining to much state in the server.
- We should look at addressing the current limitations wrt matching the
provider up to the url and also the intent in the SOAPAction header because
these shortcomings are a big chunk of why the 'page' lifecycle doesn't make
sense.
Blaine
Sanjiva Weerawarana wrote:
> - page meant all hits to the same page had the same object .. this one's
> very flaky for our scenario because all hits are delivered via
> rpcrouter.jsp. This definitely needs to be dropped.
Re: PROPOSAL on scopes (was: Re: Java Sevlet Implementation -
Attachment)
Posted by Blaine Horrocks <bl...@cp.net>.
While from an rpc perspective the application, session and request semantics
are pretty clear you could make a case for the pages semantics also. The
real problem is that the semantics are different. The first three express
semantics relative to state involving the user and the implementation of the
behaviour (i.e. how much state the implementation can hold across requests).
Page semantics otoh, reflect semantics between the user, implementation, and
also the resource identified by the url, making it confusing.
Really this is just another aspect of whether the soap spec should be tied to
http as a transport. Now, according to the present spec if you have the header
=> SOAPAction: "" <= in your http url indicates the intent (target?) of the
rpc. Naturally this would be a page in html-land. It would almost require
the 'page' lifecycle if you were intending to share resource state over
multiple users unless you were willing to reread it from persistent storage for
each request. Rereading it is of course the accepted way that TP monitors
achieve load balancing. <g>
Now it would be nice to have some way to target various resources using RPC as
well as through a browser. If you think MVC, or just MV in this case, the
resource becomes the model, and the choice of representation would depend on
whether you accessed by requestiong a soap rpc or just a page view. Which
I think may have been the original intent of the SOAPAction binding.
Apache-soap uses the method name namespace urn as the "target" of the rpc,
which is actually wrong wrt the spec. The spec states (section 7) that "For
example, for HTTP the request URI indicates the resource that the invocation is
being made against". If this is really true then 'page' sematics can make
sense.
Long and the short of it?
- Page lifecycle does make sense from the spec but we probably don't want to
support it because it implies maintaining to much state in the server.
- We should look at addressing the current limitations wrt matching the
provider up to the url and also the intent in the SOAPAction header because
these shortcomings are a big chunk of why the 'page' lifecycle doesn't make
sense.
Blaine
Sanjiva Weerawarana wrote:
> - page meant all hits to the same page had the same object .. this one's
> very flaky for our scenario because all hits are delivered via
> rpcrouter.jsp. This definitely needs to be dropped.
PROPOSAL on scopes (was: Re: Java Sevlet Implementation - Attachment)
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Steven J. McDowall writes:
> Thus, I was asking for a clarification on what is EXACTLY meant for the
> lifecycle
> of each scope.. I.e. how long do the objects live? This should probably be
> documented somewhere anyway since I am sure a lot of people don't know for
> SURE
> what the life of an object is yet..
This is what we had in mind when we came up with it .. it of course can
(and should be) revisited any time:
- we wanted to allow the user to use instance methods and not only
static methods
- that meant we had to decide when and where to instantiate the class
and how long to keep it
- the simple solution was to build on existing stuff: so we used the
JSP useBean's scopes of application, session, page, request.
- application means one instance is created for the web app and used
for all requests for that service. So if two people are using the
service at once then since the web app here is the rpcrouter.jsp,
all requests would be handled by the one single instance.
- sessions means one instance is created for the HTTP session and
used for all requests via that session. We never pursued this much
because we never got around to writing a client that kept a session
alive and did stuff.
- page meant all hits to the same page had the same object .. this one's
very flaky for our scenario because all hits are delivered via
rpcrouter.jsp. This definitely needs to be dropped.
- request meant that the object is created to handle the request and
then it goes away.
So what I suggest is the following: we support "application", "session"
and "request" with the semantics of one instance for all, one instance
per session and one instance per request, respectively. I can even
implement this correctly in the servlet ..
If we all agree, then I'll deprecate the page scope by making the
service manager except if someone tries to deploy a service with that
scope.
The servlet is working ok now; I'll change to support the above and
commit it. We can always change if there's no agreement on the above
proposal.
Sanjiva.
PROPOSAL on scopes (was: Re: Java Sevlet Implementation - Attachment)
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Steven J. McDowall writes:
> Thus, I was asking for a clarification on what is EXACTLY meant for the
> lifecycle
> of each scope.. I.e. how long do the objects live? This should probably be
> documented somewhere anyway since I am sure a lot of people don't know for
> SURE
> what the life of an object is yet..
This is what we had in mind when we came up with it .. it of course can
(and should be) revisited any time:
- we wanted to allow the user to use instance methods and not only
static methods
- that meant we had to decide when and where to instantiate the class
and how long to keep it
- the simple solution was to build on existing stuff: so we used the
JSP useBean's scopes of application, session, page, request.
- application means one instance is created for the web app and used
for all requests for that service. So if two people are using the
service at once then since the web app here is the rpcrouter.jsp,
all requests would be handled by the one single instance.
- sessions means one instance is created for the HTTP session and
used for all requests via that session. We never pursued this much
because we never got around to writing a client that kept a session
alive and did stuff.
- page meant all hits to the same page had the same object .. this one's
very flaky for our scenario because all hits are delivered via
rpcrouter.jsp. This definitely needs to be dropped.
- request meant that the object is created to handle the request and
then it goes away.
So what I suggest is the following: we support "application", "session"
and "request" with the semantics of one instance for all, one instance
per session and one instance per request, respectively. I can even
implement this correctly in the servlet ..
If we all agree, then I'll deprecate the page scope by making the
service manager except if someone tries to deploy a service with that
scope.
The servlet is working ok now; I'll change to support the above and
commit it. We can always change if there's no agreement on the above
proposal.
Sanjiva.
RE: Java Sevlet Implementation - Attachment
Posted by "Steven J. McDowall" <sj...@uswest.net>.
-----Original Message-----
Steven J. McDowall writes:
>>Note that not all errors are to be returned as SOAP faults; see the
>>spec for details.
Anything we don't return as a Fault, however, gets thrown as an exception
back to the client because it is then "bad XML" to the parser.. So, instead
of the client generating a "clean error message", it throws an exception
with
a long stack trace in the middle of SAX.
Although allowable my the spec, our implementation actually appears to
"demand" a nice fault code coming back whenever possible.
>> Hopefully this code (and the README text, etc. ) will go into the
standard
>> xml-soap CVS somewhere (with the proper apache disclaimer headers, etc.)
>> as version 1.0, and from there I can fix these up and also approach the
>> synchronization issue..
>I have three drafts of servletifying rpcrouter.jsp: yours, someone else
>who sent it to me direct, and my own. I'm going to try to merge it all
>and commit a version in the next hour or so.
Great! Hopefully between the three we have exactly what we need
and a little more.. :-)
> Sanjiva or anyone, could someone explain WHAT was the thinking behind
> the various scope, iScope, scopeids, etc. and how that related to
> synch. and how we should approach in a servlet context? :-)
>That's how lifecycle management is done of the object providing the
>service. When you deploy a service the author indicates what scope
>should be used to new the class (unless it is static of course): request,
>page, session or application. The router creates the object under that
>scope and manages it and routes requests to the appropriate instance.
>We cannot just dump that code (as your servlet appears to) unless we
>also remove that logic from the deployment stuff. I don't want to make
>such a change for this version; I'm all for a better way to do
>lifecycle management however because the current model doesn't work
>when the messages are carried over JMS, say.
>How to approach it? Take a look at the servle>t generated by the JSP
>compiler; you'll see exactly how to handle it> ..
Actually, my version does do SOME lifecycle management, just probably
too much. :-) It also creates an object instance under each scope TYPE, but
just keeps it already forever...
I DID look at the compiled code, however, there is some "JSP" magic
being done I am not familiar (not being JSP inclined..) Specifically
it appears the "caching" technique uses a JSP specific "getAttribute"
and "setAttribute" pageContext method calls.. I assume that somehow
these calls, for each context, is auto handled by "Jasper" or whomever
to manage the "scope"..
Thus, I was asking for a clarification on what is EXACTLY meant for the
lifecycle
of each scope.. I.e. how long do the objects live? This should probably be
documented somewhere anyway since I am sure a lot of people don't know for
SURE
what the life of an object is yet..
-Steve
RE: Java Sevlet Implementation - Attachment
Posted by "Steven J. McDowall" <sj...@uswest.net>.
-----Original Message-----
Steven J. McDowall writes:
>>Note that not all errors are to be returned as SOAP faults; see the
>>spec for details.
Anything we don't return as a Fault, however, gets thrown as an exception
back to the client because it is then "bad XML" to the parser.. So, instead
of the client generating a "clean error message", it throws an exception
with
a long stack trace in the middle of SAX.
Although allowable my the spec, our implementation actually appears to
"demand" a nice fault code coming back whenever possible.
>> Hopefully this code (and the README text, etc. ) will go into the
standard
>> xml-soap CVS somewhere (with the proper apache disclaimer headers, etc.)
>> as version 1.0, and from there I can fix these up and also approach the
>> synchronization issue..
>I have three drafts of servletifying rpcrouter.jsp: yours, someone else
>who sent it to me direct, and my own. I'm going to try to merge it all
>and commit a version in the next hour or so.
Great! Hopefully between the three we have exactly what we need
and a little more.. :-)
> Sanjiva or anyone, could someone explain WHAT was the thinking behind
> the various scope, iScope, scopeids, etc. and how that related to
> synch. and how we should approach in a servlet context? :-)
>That's how lifecycle management is done of the object providing the
>service. When you deploy a service the author indicates what scope
>should be used to new the class (unless it is static of course): request,
>page, session or application. The router creates the object under that
>scope and manages it and routes requests to the appropriate instance.
>We cannot just dump that code (as your servlet appears to) unless we
>also remove that logic from the deployment stuff. I don't want to make
>such a change for this version; I'm all for a better way to do
>lifecycle management however because the current model doesn't work
>when the messages are carried over JMS, say.
>How to approach it? Take a look at the servle>t generated by the JSP
>compiler; you'll see exactly how to handle it> ..
Actually, my version does do SOME lifecycle management, just probably
too much. :-) It also creates an object instance under each scope TYPE, but
just keeps it already forever...
I DID look at the compiled code, however, there is some "JSP" magic
being done I am not familiar (not being JSP inclined..) Specifically
it appears the "caching" technique uses a JSP specific "getAttribute"
and "setAttribute" pageContext method calls.. I assume that somehow
these calls, for each context, is auto handled by "Jasper" or whomever
to manage the "scope"..
Thus, I was asking for a clarification on what is EXACTLY meant for the
lifecycle
of each scope.. I.e. how long do the objects live? This should probably be
documented somewhere anyway since I am sure a lot of people don't know for
SURE
what the life of an object is yet..
-Steve
Re: Java Sevlet Implementation - Attachment
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Steven J. McDowall writes:
> 2) As for the try/catch you mentioned. I wondered about this too, and
> it probably should be changed. I didn't want to change the behavior of
> the first version TOO much from the jsp, including bad behavior. :-)
The response part is not "expected" to throw exceptions (by that time
all the reasons that could cause them should've been checked), however,
I agree that that should be done within a try/catch.
Note that not all errors are to be returned as SOAP faults; see the
spec for details.
> Hopefully this code (and the README text, etc. ) will go into the standard
> xml-soap CVS somewhere (with the proper apache disclaimer headers, etc.)
> as version 1.0, and from there I can fix these up and also approach the
> synchronization issue..
I have three drafts of servletifying rpcrouter.jsp: yours, someone else
who sent it to me direct, and my own. I'm going to try to merge it all
and commit a version in the next hour or so.
> Sanjiva or anyone, could someone explain WHAT was the thinking behind
> the various scope, iScope, scopeids, etc. and how that related to
> synch. and how we should approach in a servlet context? :-)
That's how lifecycle management is done of the object providing the
service. When you deploy a service the author indicates what scope
should be used to new the class (unless it is static of course): request,
page, session or application. The router creates the object under that
scope and manages it and routes requests to the appropriate instance.
We cannot just dump that code (as your servlet appears to) unless we
also remove that logic from the deployment stuff. I don't want to make
such a change for this version; I'm all for a better way to do
lifecycle management however because the current model doesn't work
when the messages are carried over JMS, say.
How to approach it? Take a look at the servlet generated by the JSP
compiler; you'll see exactly how to handle it ..
Sanjiva.
Re: Java Sevlet Implementation - Attachment
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Steven J. McDowall writes:
> 2) As for the try/catch you mentioned. I wondered about this too, and
> it probably should be changed. I didn't want to change the behavior of
> the first version TOO much from the jsp, including bad behavior. :-)
The response part is not "expected" to throw exceptions (by that time
all the reasons that could cause them should've been checked), however,
I agree that that should be done within a try/catch.
Note that not all errors are to be returned as SOAP faults; see the
spec for details.
> Hopefully this code (and the README text, etc. ) will go into the standard
> xml-soap CVS somewhere (with the proper apache disclaimer headers, etc.)
> as version 1.0, and from there I can fix these up and also approach the
> synchronization issue..
I have three drafts of servletifying rpcrouter.jsp: yours, someone else
who sent it to me direct, and my own. I'm going to try to merge it all
and commit a version in the next hour or so.
> Sanjiva or anyone, could someone explain WHAT was the thinking behind
> the various scope, iScope, scopeids, etc. and how that related to
> synch. and how we should approach in a servlet context? :-)
That's how lifecycle management is done of the object providing the
service. When you deploy a service the author indicates what scope
should be used to new the class (unless it is static of course): request,
page, session or application. The router creates the object under that
scope and manages it and routes requests to the appropriate instance.
We cannot just dump that code (as your servlet appears to) unless we
also remove that logic from the deployment stuff. I don't want to make
such a change for this version; I'm all for a better way to do
lifecycle management however because the current model doesn't work
when the messages are carried over JMS, say.
How to approach it? Take a look at the servlet generated by the JSP
compiler; you'll see exactly how to handle it ..
Sanjiva.
RE: Java Sevlet Implementation - Attachment
Posted by "Steven J. McDowall" <sj...@uswest.net>.
Thanks for the input Wouter..
1) As for the Get Method.. Well, that's just my old Servlet Template
which I didn't think to remove.. When at all possible, I like to be
flexible.. However, for SOAP your right.. Even I can't imagine how someone
would get a SOAP payload through a GET method.. :-)
2) As for the try/catch you mentioned. I wondered about this too, and
it probably should be changed. I didn't want to change the behavior of
the first version TOO much from the jsp, including bad behavior. :-)
Hopefully this code (and the README text, etc. ) will go into the standard
xml-soap CVS somewhere (with the proper apache disclaimer headers, etc.)
as version 1.0, and from there I can fix these up and also approach the
synchronization issue..
Sanjiva or anyone, could someone explain WHAT was the thinking behind
the various scope, iScope, scopeids, etc. and how that related to
synch. and how we should approach in a servlet context? :-)
-Steve
-----Original Message-----
From: Wouter Cloetens [mailto:wcloeten@raleigh.ibm.com]
Sent: Thursday, August 03, 2000 1:07 AM
To: soap-dev@xml.apache.org
Subject: Re: Java Sevlet Implementation - Attachment
On Thu, 3 Aug 2000 10:52:17 -0500, Steven J. McDowall wrote:
>I have finished a PRELIMINARY Servlet version of rpcrouter.jsp.
Good work. I'm especially happy with the Unicode support. :-)
Hmm, why would you support the GET method in it? That can't deliver a SOAP
payload.
Only POST and PUT have content...
Another problem with the JSP version that's still in the servlet version, is
that the try block
to catch SOAPExceptions and then return SOAP faults, does not extend over
the part at
the bottom that builds the response. That part can also throw
SOAPExceptions, which will
let the servlet engine send some HTML error page it generates itself. Even
the
SOAPException catch block doesn't always return a valid SOAP error response
(just a
message or a stack trace sometimes).
bfn, Wouter
--
http://www.workspot.net/~zombie/soap/
My opinions are irrelevant. They will be assimilated by my employer.
RE: Java Sevlet Implementation - Attachment
Posted by "Steven J. McDowall" <sj...@uswest.net>.
Thanks for the input Wouter..
1) As for the Get Method.. Well, that's just my old Servlet Template
which I didn't think to remove.. When at all possible, I like to be
flexible.. However, for SOAP your right.. Even I can't imagine how someone
would get a SOAP payload through a GET method.. :-)
2) As for the try/catch you mentioned. I wondered about this too, and
it probably should be changed. I didn't want to change the behavior of
the first version TOO much from the jsp, including bad behavior. :-)
Hopefully this code (and the README text, etc. ) will go into the standard
xml-soap CVS somewhere (with the proper apache disclaimer headers, etc.)
as version 1.0, and from there I can fix these up and also approach the
synchronization issue..
Sanjiva or anyone, could someone explain WHAT was the thinking behind
the various scope, iScope, scopeids, etc. and how that related to
synch. and how we should approach in a servlet context? :-)
-Steve
-----Original Message-----
From: Wouter Cloetens [mailto:wcloeten@raleigh.ibm.com]
Sent: Thursday, August 03, 2000 1:07 AM
To: soap-dev@xml.apache.org
Subject: Re: Java Sevlet Implementation - Attachment
On Thu, 3 Aug 2000 10:52:17 -0500, Steven J. McDowall wrote:
>I have finished a PRELIMINARY Servlet version of rpcrouter.jsp.
Good work. I'm especially happy with the Unicode support. :-)
Hmm, why would you support the GET method in it? That can't deliver a SOAP
payload.
Only POST and PUT have content...
Another problem with the JSP version that's still in the servlet version, is
that the try block
to catch SOAPExceptions and then return SOAP faults, does not extend over
the part at
the bottom that builds the response. That part can also throw
SOAPExceptions, which will
let the servlet engine send some HTML error page it generates itself. Even
the
SOAPException catch block doesn't always return a valid SOAP error response
(just a
message or a stack trace sometimes).
bfn, Wouter
--
http://www.workspot.net/~zombie/soap/
My opinions are irrelevant. They will be assimilated by my employer.