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 Doug Davis/Raleigh/IBM <du...@us.ibm.com> on 2000/10/27 17:06:03 UTC
Pluggable Providers
All,
We have some code changes that we'd like to see put into the v2.0
SOAP code. They basically involve 2 different changes:
1 - Support for pluggable providers
2 - Support for an optional key in URNs
More (but concise) details:
1 - Allows users to specify a classname in place of "java" or
"script" in the provider 'type' element of the deployment
descriptor xml file. For example:
<isd:provider type="com.foo.providers.MyProvider"
scope="Application" methods="doit">
<isd:java class="myobject"/>
This will indicate to the SOAP server that instead of simply
loading 'myobject' and calling 'doit', it should load
'com.foo.providers.MyProvider' and let it call 'doit'. This allows
'myobject' to be something other than a java class (ie. maybe an
EXE, or an EJB...). The point being that it's up to 'MyProvider'
to know/figure out how to locate and load 'myobject' and then
invoke 'doit'. It's also its job to locate/process whatever
return values it should return back to the SOAP client in a
Response object.
The code for processing the 'normal' SOAP services (ie. java
and scripts) is still there but the logic that was in RPCRouterServlet
is now in a JavaProvider. This should eventually be split into
a Java and BSF provider (but that can come after this initial change
is approved).
A key point here is that if a user continues to use either 'java'
or 'script' in the 'type' tag then nothing changes and everything
works just like it does today - this new logic will only kick in
if they want to use a specialized provider.
Along with this is a minor change to the Deployment Descriptor
file. With the addition of pluggable providers we saw the need
for options to be passed in to the provider, so we added support
any number of name/value pairing elements to the DD file.
In the <isd:provider> section we allow:
<isd:option key="aaa" value="bbb" />
This information will be stored in the deployment descriptor
and will be available to the Provider at runtime.
One of the reasons for making this change was to support EJBs, and
in the next day or two we'll submit code for an EJBProvider (just
working through a few technical glitches right now). But, in order
to support EJBs we needed to also make the next change...
2 - Add support for an optional 'instance-id' in the URN. Here we've
added support for a URN to contain an optional unique identifier
so that providers that need them (like an EJB provider) can use
this information to identify the object to load. The format
we've chosen is:
urn:service[@instance-id]
The code will search the urn for '@' and remove it and all chars
after it before it searches the deployment descriptor database.
However, once it finds the correct DD, it will then pass the full
URN on to the provider so it can use the optional 'instance-id' in
its searching algorithm. In the EJB case it will allow us to find
stateful and entity beans.
In the zip file is a new sample that uses a TemplateProvider to demo
this new feature. It doesn't really do anything other than print debug
info to stderr. But its a starting point for future providers.
There are some future pieces of work that will need to be done
but we wanted to get this part run thought the system first.
Attached are the new/changed files. (See attached file: provider.zip)
Comments/Feedback/Additonal info needed?
(Approval? 8-)
thanks,
-Dug
dug@us.ibm.com
Re: Pluggable Providers
Posted by "Diane L. Davison" <Di...@oracle.com>.
In the Provider interface, you might consider using a SOAPContext parameter instead of
passing in the servlet and session. Check out the SOAP v3 discussions for more
information.
I think it is a very bad idea to put provider-specific information in the service
URN. This has been discussed previously on this list. I thought there was a
consensus, but that might be assuming too much.
Diane
Doug Davis/Raleigh/IBM wrote:
> All,
> We have some code changes that we'd like to see put into the v2.0
> SOAP code. They basically involve 2 different changes:
> 1 - Support for pluggable providers
> 2 - Support for an optional key in URNs
>
> More (but concise) details:
> 1 - Allows users to specify a classname in place of "java" or
> "script" in the provider 'type' element of the deployment
> descriptor xml file. For example:
> <isd:provider type="com.foo.providers.MyProvider"
> scope="Application" methods="doit">
> <isd:java class="myobject"/>
> This will indicate to the SOAP server that instead of simply
> loading 'myobject' and calling 'doit', it should load
> 'com.foo.providers.MyProvider' and let it call 'doit'. This allows
> 'myobject' to be something other than a java class (ie. maybe an
> EXE, or an EJB...). The point being that it's up to 'MyProvider'
> to know/figure out how to locate and load 'myobject' and then
> invoke 'doit'. It's also its job to locate/process whatever
> return values it should return back to the SOAP client in a
> Response object.
>
> The code for processing the 'normal' SOAP services (ie. java
> and scripts) is still there but the logic that was in RPCRouterServlet
> is now in a JavaProvider. This should eventually be split into
> a Java and BSF provider (but that can come after this initial change
> is approved).
>
> A key point here is that if a user continues to use either 'java'
> or 'script' in the 'type' tag then nothing changes and everything
> works just like it does today - this new logic will only kick in
> if they want to use a specialized provider.
>
> Along with this is a minor change to the Deployment Descriptor
> file. With the addition of pluggable providers we saw the need
> for options to be passed in to the provider, so we added support
> any number of name/value pairing elements to the DD file.
> In the <isd:provider> section we allow:
> <isd:option key="aaa" value="bbb" />
> This information will be stored in the deployment descriptor
> and will be available to the Provider at runtime.
>
> One of the reasons for making this change was to support EJBs, and
> in the next day or two we'll submit code for an EJBProvider (just
> working through a few technical glitches right now). But, in order
> to support EJBs we needed to also make the next change...
>
> 2 - Add support for an optional 'instance-id' in the URN. Here we've
> added support for a URN to contain an optional unique identifier
> so that providers that need them (like an EJB provider) can use
> this information to identify the object to load. The format
> we've chosen is:
> urn:service[@instance-id]
> The code will search the urn for '@' and remove it and all chars
> after it before it searches the deployment descriptor database.
> However, once it finds the correct DD, it will then pass the full
> URN on to the provider so it can use the optional 'instance-id' in
> its searching algorithm. In the EJB case it will allow us to find
> stateful and entity beans.
>
> In the zip file is a new sample that uses a TemplateProvider to demo
> this new feature. It doesn't really do anything other than print debug
> info to stderr. But its a starting point for future providers.
>
> There are some future pieces of work that will need to be done
> but we wanted to get this part run thought the system first.
>
> Attached are the new/changed files. (See attached file: provider.zip)
>
> Comments/Feedback/Additonal info needed?
> (Approval? 8-)
>
> thanks,
> -Dug
> dug@us.ibm.com
>
> --------------------------------------------------------------------------------
> Name: provider.zip
> Type: Zip Compressed Data (application/x-zip-compressed)
> provider.zip Encoding: base64
> Description: .ZIP File
> Download Status: Not downloaded with message
Re: Pluggable Providers
Posted by "Diane L. Davison" <Di...@oracle.com>.
In the Provider interface, you might consider using a SOAPContext parameter instead of
passing in the servlet and session. Check out the SOAP v3 discussions for more
information.
I think it is a very bad idea to put provider-specific information in the service
URN. This has been discussed previously on this list. I thought there was a
consensus, but that might be assuming too much.
Diane
Doug Davis/Raleigh/IBM wrote:
> All,
> We have some code changes that we'd like to see put into the v2.0
> SOAP code. They basically involve 2 different changes:
> 1 - Support for pluggable providers
> 2 - Support for an optional key in URNs
>
> More (but concise) details:
> 1 - Allows users to specify a classname in place of "java" or
> "script" in the provider 'type' element of the deployment
> descriptor xml file. For example:
> <isd:provider type="com.foo.providers.MyProvider"
> scope="Application" methods="doit">
> <isd:java class="myobject"/>
> This will indicate to the SOAP server that instead of simply
> loading 'myobject' and calling 'doit', it should load
> 'com.foo.providers.MyProvider' and let it call 'doit'. This allows
> 'myobject' to be something other than a java class (ie. maybe an
> EXE, or an EJB...). The point being that it's up to 'MyProvider'
> to know/figure out how to locate and load 'myobject' and then
> invoke 'doit'. It's also its job to locate/process whatever
> return values it should return back to the SOAP client in a
> Response object.
>
> The code for processing the 'normal' SOAP services (ie. java
> and scripts) is still there but the logic that was in RPCRouterServlet
> is now in a JavaProvider. This should eventually be split into
> a Java and BSF provider (but that can come after this initial change
> is approved).
>
> A key point here is that if a user continues to use either 'java'
> or 'script' in the 'type' tag then nothing changes and everything
> works just like it does today - this new logic will only kick in
> if they want to use a specialized provider.
>
> Along with this is a minor change to the Deployment Descriptor
> file. With the addition of pluggable providers we saw the need
> for options to be passed in to the provider, so we added support
> any number of name/value pairing elements to the DD file.
> In the <isd:provider> section we allow:
> <isd:option key="aaa" value="bbb" />
> This information will be stored in the deployment descriptor
> and will be available to the Provider at runtime.
>
> One of the reasons for making this change was to support EJBs, and
> in the next day or two we'll submit code for an EJBProvider (just
> working through a few technical glitches right now). But, in order
> to support EJBs we needed to also make the next change...
>
> 2 - Add support for an optional 'instance-id' in the URN. Here we've
> added support for a URN to contain an optional unique identifier
> so that providers that need them (like an EJB provider) can use
> this information to identify the object to load. The format
> we've chosen is:
> urn:service[@instance-id]
> The code will search the urn for '@' and remove it and all chars
> after it before it searches the deployment descriptor database.
> However, once it finds the correct DD, it will then pass the full
> URN on to the provider so it can use the optional 'instance-id' in
> its searching algorithm. In the EJB case it will allow us to find
> stateful and entity beans.
>
> In the zip file is a new sample that uses a TemplateProvider to demo
> this new feature. It doesn't really do anything other than print debug
> info to stderr. But its a starting point for future providers.
>
> There are some future pieces of work that will need to be done
> but we wanted to get this part run thought the system first.
>
> Attached are the new/changed files. (See attached file: provider.zip)
>
> Comments/Feedback/Additonal info needed?
> (Approval? 8-)
>
> thanks,
> -Dug
> dug@us.ibm.com
>
> --------------------------------------------------------------------------------
> Name: provider.zip
> Type: Zip Compressed Data (application/x-zip-compressed)
> provider.zip Encoding: base64
> Description: .ZIP File
> Download Status: Not downloaded with message