axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark D Weitzel" <weitz...@us.ibm.com>
Subject Re: Pluggable Providers
Date Fri, 09 Mar 2001 16:54:27 GMT
If pluggable providers are handlers does this mean that I will have to code
a java handler to invoke my non-java provider that i'm plugging in?
Granted, I'm not sure how pluggable providers work now, but I would think
that there could be some generic handler that works in conjunction with a
deployment descriptor of some kind that gets you to your 'plugged
provider'.  If the provider is a handler, then you could just drop in the
plugged provider somewhere in the chain.

So a deployment descriptor for a pluggable provider handler might look
something like...

<isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment"
             id="urn:live-stock-quotes">
  <isd:provider type="smalltalk"
                scope="Application"
                methods="getQuote"
     location="http://mySmalltalkServer:80/rpcrouter">
    <isd:smalltalk providerKey="StockQuoteService" >
  </isd:provider>
</isd:service>

If the pluggable provider is placed in the beginning of the chain, then
parsing issues are somewhat minimized.  However, how do you manage the
first part of the chain parsing the headers, then encountering a 'pluggable
provider' handler?  Should the entire message be passed into the plugged
provider?  Only the remaing part?

Of course if you work for MTV, you would have an 'UnPlugged' Provider? ;-)

-mw
________________________________________
Mark Weitzel
IBM Smalltalk Group
Phone (919) 838 3264
internet: weitzelm@us.ibm.com
"Never try to catch a falling knife."


Doug Davis/Raleigh/IBM@IBMUS on 03/09/2001 09:09:51 AM

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
Subject:  Pluggable Providers



How are we going to do pluggable providers in Axis?
Are they handlers or are they something that the
handler calls?  I'd like to verify with everyone that
they're going to be handlers and not something that
gets plugged into a handler (or something that the
pivot point handler calls).  The main reasons I see
for making them a handler is that they need access
to everything - headers as well as bodies - and that
we have no idea what they're going to do, so we
can't even deserialize anything in advance (in the
rpc cases).  Is everyone on the same page with this?
-Dug




Mime
View raw message