SOAPDispatcher, SOAPDescription

[Jacek Kopecky <ja...@idoox.com>]

  Hello. 8-)
  Hope you had a good chat today, I was sitting on a train at that
time... Could anyone post a log here?
  Anyways, here are my thoughts on the SOAPDescription issues.

  First, since a service description is only a small part of the
server configuration I decided to tackle the whole of it.
  When a server receives a message, all it knows about the message is
the URL it came to, in some cases the SOAPAction header, and finally
the message itself - headers and the body.
  First dispatching should occur only on the first two pieces of
information because they are available with completely no parsing and
thus can be sped up. So I divide the dispatching to two
phases: pre-parse and post-parse. 
  In the pre-parse case the handlers should probably get the message
in a stream (Java) or file descriptor (C++) so that even forwarding to
other servers can be optimized (see the manpage for sendfile(2)). Here
the dispatcher configuration will say which handler will get this
message based on the URL and SOAPAction, this won't be helped much by
a service description.
  If the pre-parse handlers don't object (see below for my ideas on
how a handler can direct the following processing) the message is
parsed into some hierarchy of objects (like a DOM or SOAPEnvelope/
SOAPHeader/SOAPBody) and the following handlers will get this
hierarchy (we should probably even consider _not_ giving them
information like the URL and such). The post-parse dispatcher
configuration should also be URL(/SOAPAction) dependent.
  The post-parse dispatcher configuration could schematically say
something like this:

1)   [ Always | For <qname> | Unless <qname>'s present ] 
2)   call <class> 
3)   with [ <qname> | everything | body | nothing ]
4)   [ and with a parameter of <xml element> ]

  1) This will allow us to set some header handlers to be called
everytime we get a message (Always) or only when a specified qname
is/isn't present among the headers and the body (For <qname>, Unless
<qname>). Optional headers will be handled the latter way, the
mandatory ones and the transparent actions will be handled the former
way. Mandatory header handler will know that if it doesn't receive the
header it should complain.
  2) This specifies the class (and/or method) to be called.
  3) this specifies that the called method will receive a selected
element from among the headers and the body; everything; only the
body; or nothing. Of course the current 'context' will be passed in
every case.
  4) This is an optional parameter that can allow us to use one
handler for slightly different purposes (depending on the value of the
parameter). I think the parameter should be any general structure, a
DOM tree should do nicely. 

  Each such entry should be mapped to a combination of
URL(/SOAPAction)/body qname. 

  This all applies when everything goes smooth and OK. Sometimes a
handler wants to return a fault when some conditions are not met or
even return a response prematurely.
  I don't see any need for using more than one pre-parse handler on
any message, I even don't think pre-parse and post-parse handlers
should be used together. I see the pre-parse handlers like a way for
a light-weight routing. So the pre-parse handler can just return the
reply (probably write it right into the output stream).
  With the post-parse handlers we want to decide whether to go on or
stop right there. In Java the handlers could return the DOM/hierarchy
that should be passed on or except with the DOM/hierarchy that should
be returned with no more parsing.
  If we want to avoid exceptions for any reason in C++ we could use a
boolean return value and find the DOM/hierarchy in an in/out
parameter.

  I haven't mentioned the SOAPDescription yet. I think that our
configuration should be able to specify anything (important to the
dispatcher) that can be specified with a service description. The
description can only tell us the required structure of the messages -
this specifies what to expect. This information combined with our
database of handlers will result in such configuration structure as I
have described above.

  How do you like this? I hope I haven't come up with anything already
well discussed or even already dismissed. 8-)


                            Jacek Kopecky
                            Idoox s.r.o.

Re: SOAPDispatcher, SOAPDescription

[Jacek Kopecky <ja...@idoox.com>]

 Hi. 8-)
 I just finished reading the log and I see what I've described has
been discussed a lot today... Pity I couldn't be there...
 Anyways, my quick remarks before I go home:
 I have forgotten to split up the qnames into nsURIs and local
names. That's one more piece of information useful for generalizations
during dispatching.
 I object to James' thinking in lines of service
description. Specifically when he said

   "[13:03] <JamesSnell> we can make the binding based on URI of the
service, URI of the namespace or global for all messages on a server
or all messages on a service endpoint..."

 What I don't like is the very last part. I think that a service
endpoint is too specific a notion to be put into a general
configuration. I'd rather have the particular sdl adaptor duplicate
configuration entries when they apply to e.g. a whole SCL port. Let's
not bring ports (or whatever) into our configuration, it would only
make things unnecessarily complex when the same can be accomplished
with some init-time preprocessing.
 I envision the following sequence of configuration initialization:
1) the dispatcher reads the static configuration
2) the description handler reads the description and configures the
   dispatcher more
3) the application code does the last custom touches and runs the
   listener queues - the server goes on-line.

                            Jacek Kopecky
                            Idoox s.r.o.

P.S: so the agreement is to meet in Hawaii? 8-)



On Tue, 19 Sep 2000, Jacek Kopecky wrote:

 >   Hello. 8-)
 >   Hope you had a good chat today, I was sitting on a train at that
 > time... Could anyone post a log here?
 >   Anyways, here are my thoughts on the SOAPDescription issues.
 > 
 >   First, since a service description is only a small part of the
 > server configuration I decided to tackle the whole of it.
 >   When a server receives a message, all it knows about the message is
 > the URL it came to, in some cases the SOAPAction header, and finally
 > the message itself - headers and the body.
 >   First dispatching should occur only on the first two pieces of
 > information because they are available with completely no parsing and
 > thus can be sped up. So I divide the dispatching to two
 > phases: pre-parse and post-parse. 
 >   In the pre-parse case the handlers should probably get the message
 > in a stream (Java) or file descriptor (C++) so that even forwarding to
 > other servers can be optimized (see the manpage for sendfile(2)). Here
 > the dispatcher configuration will say which handler will get this
 > message based on the URL and SOAPAction, this won't be helped much by
 > a service description.
 >   If the pre-parse handlers don't object (see below for my ideas on
 > how a handler can direct the following processing) the message is
 > parsed into some hierarchy of objects (like a DOM or SOAPEnvelope/
 > SOAPHeader/SOAPBody) and the following handlers will get this
 > hierarchy (we should probably even consider _not_ giving them
 > information like the URL and such). The post-parse dispatcher
 > configuration should also be URL(/SOAPAction) dependent.
 >   The post-parse dispatcher configuration could schematically say
 > something like this:
 > 
 > 1)   [ Always | For <qname> | Unless <qname>'s present ] 
 > 2)   call <class> 
 > 3)   with [ <qname> | everything | body | nothing ]
 > 4)   [ and with a parameter of <xml element> ]
 > 
 >   1) This will allow us to set some header handlers to be called
 > everytime we get a message (Always) or only when a specified qname
 > is/isn't present among the headers and the body (For <qname>, Unless
 > <qname>). Optional headers will be handled the latter way, the
 > mandatory ones and the transparent actions will be handled the former
 > way. Mandatory header handler will know that if it doesn't receive the
 > header it should complain.
 >   2) This specifies the class (and/or method) to be called.
 >   3) this specifies that the called method will receive a selected
 > element from among the headers and the body; everything; only the
 > body; or nothing. Of course the current 'context' will be passed in
 > every case.
 >   4) This is an optional parameter that can allow us to use one
 > handler for slightly different purposes (depending on the value of the
 > parameter). I think the parameter should be any general structure, a
 > DOM tree should do nicely. 
 > 
 >   Each such entry should be mapped to a combination of
 > URL(/SOAPAction)/body qname. 
 > 
 >   This all applies when everything goes smooth and OK. Sometimes a
 > handler wants to return a fault when some conditions are not met or
 > even return a response prematurely.
 >   I don't see any need for using more than one pre-parse handler on
 > any message, I even don't think pre-parse and post-parse handlers
 > should be used together. I see the pre-parse handlers like a way for
 > a light-weight routing. So the pre-parse handler can just return the
 > reply (probably write it right into the output stream).
 >   With the post-parse handlers we want to decide whether to go on or
 > stop right there. In Java the handlers could return the DOM/hierarchy
 > that should be passed on or except with the DOM/hierarchy that should
 > be returned with no more parsing.
 >   If we want to avoid exceptions for any reason in C++ we could use a
 > boolean return value and find the DOM/hierarchy in an in/out
 > parameter.
 > 
 >   I haven't mentioned the SOAPDescription yet. I think that our
 > configuration should be able to specify anything (important to the
 > dispatcher) that can be specified with a service description. The
 > description can only tell us the required structure of the messages -
 > this specifies what to expect. This information combined with our
 > database of handlers will result in such configuration structure as I
 > have described above.
 > 
 >   How do you like this? I hope I haven't come up with anything already
 > well discussed or even already dismissed. 8-)
 > 
 > 
 >                             Jacek Kopecky
 >                             Idoox s.r.o.
 > 
 > 
 > 

Re: SOAPDispatcher, SOAPDescription

[Jacek Kopecky <ja...@idoox.com>]

 Hi. 8-)
 I just finished reading the log and I see what I've described has
been discussed a lot today... Pity I couldn't be there...
 Anyways, my quick remarks before I go home:
 I have forgotten to split up the qnames into nsURIs and local
names. That's one more piece of information useful for generalizations
during dispatching.
 I object to James' thinking in lines of service
description. Specifically when he said

   "[13:03] <JamesSnell> we can make the binding based on URI of the
service, URI of the namespace or global for all messages on a server
or all messages on a service endpoint..."

 What I don't like is the very last part. I think that a service
endpoint is too specific a notion to be put into a general
configuration. I'd rather have the particular sdl adaptor duplicate
configuration entries when they apply to e.g. a whole SCL port. Let's
not bring ports (or whatever) into our configuration, it would only
make things unnecessarily complex when the same can be accomplished
with some init-time preprocessing.
 I envision the following sequence of configuration initialization:
1) the dispatcher reads the static configuration
2) the description handler reads the description and configures the
   dispatcher more
3) the application code does the last custom touches and runs the
   listener queues - the server goes on-line.

                            Jacek Kopecky
                            Idoox s.r.o.

P.S: so the agreement is to meet in Hawaii? 8-)



On Tue, 19 Sep 2000, Jacek Kopecky wrote:

 >   Hello. 8-)
 >   Hope you had a good chat today, I was sitting on a train at that
 > time... Could anyone post a log here?
 >   Anyways, here are my thoughts on the SOAPDescription issues.
 > 
 >   First, since a service description is only a small part of the
 > server configuration I decided to tackle the whole of it.
 >   When a server receives a message, all it knows about the message is
 > the URL it came to, in some cases the SOAPAction header, and finally
 > the message itself - headers and the body.
 >   First dispatching should occur only on the first two pieces of
 > information because they are available with completely no parsing and
 > thus can be sped up. So I divide the dispatching to two
 > phases: pre-parse and post-parse. 
 >   In the pre-parse case the handlers should probably get the message
 > in a stream (Java) or file descriptor (C++) so that even forwarding to
 > other servers can be optimized (see the manpage for sendfile(2)). Here
 > the dispatcher configuration will say which handler will get this
 > message based on the URL and SOAPAction, this won't be helped much by
 > a service description.
 >   If the pre-parse handlers don't object (see below for my ideas on
 > how a handler can direct the following processing) the message is
 > parsed into some hierarchy of objects (like a DOM or SOAPEnvelope/
 > SOAPHeader/SOAPBody) and the following handlers will get this
 > hierarchy (we should probably even consider _not_ giving them
 > information like the URL and such). The post-parse dispatcher
 > configuration should also be URL(/SOAPAction) dependent.
 >   The post-parse dispatcher configuration could schematically say
 > something like this:
 > 
 > 1)   [ Always | For <qname> | Unless <qname>'s present ] 
 > 2)   call <class> 
 > 3)   with [ <qname> | everything | body | nothing ]
 > 4)   [ and with a parameter of <xml element> ]
 > 
 >   1) This will allow us to set some header handlers to be called
 > everytime we get a message (Always) or only when a specified qname
 > is/isn't present among the headers and the body (For <qname>, Unless
 > <qname>). Optional headers will be handled the latter way, the
 > mandatory ones and the transparent actions will be handled the former
 > way. Mandatory header handler will know that if it doesn't receive the
 > header it should complain.
 >   2) This specifies the class (and/or method) to be called.
 >   3) this specifies that the called method will receive a selected
 > element from among the headers and the body; everything; only the
 > body; or nothing. Of course the current 'context' will be passed in
 > every case.
 >   4) This is an optional parameter that can allow us to use one
 > handler for slightly different purposes (depending on the value of the
 > parameter). I think the parameter should be any general structure, a
 > DOM tree should do nicely. 
 > 
 >   Each such entry should be mapped to a combination of
 > URL(/SOAPAction)/body qname. 
 > 
 >   This all applies when everything goes smooth and OK. Sometimes a
 > handler wants to return a fault when some conditions are not met or
 > even return a response prematurely.
 >   I don't see any need for using more than one pre-parse handler on
 > any message, I even don't think pre-parse and post-parse handlers
 > should be used together. I see the pre-parse handlers like a way for
 > a light-weight routing. So the pre-parse handler can just return the
 > reply (probably write it right into the output stream).
 >   With the post-parse handlers we want to decide whether to go on or
 > stop right there. In Java the handlers could return the DOM/hierarchy
 > that should be passed on or except with the DOM/hierarchy that should
 > be returned with no more parsing.
 >   If we want to avoid exceptions for any reason in C++ we could use a
 > boolean return value and find the DOM/hierarchy in an in/out
 > parameter.
 > 
 >   I haven't mentioned the SOAPDescription yet. I think that our
 > configuration should be able to specify anything (important to the
 > dispatcher) that can be specified with a service description. The
 > description can only tell us the required structure of the messages -
 > this specifies what to expect. This information combined with our
 > database of handlers will result in such configuration structure as I
 > have described above.
 > 
 >   How do you like this? I hope I haven't come up with anything already
 > well discussed or even already dismissed. 8-)
 > 
 > 
 >                             Jacek Kopecky
 >                             Idoox s.r.o.
 > 
 > 
 >