Hi,
There are two kinds of ways you can go to access *a particular* web service:
1. Stub invocation:
Use the WSDL to generate java classes and a stub interface.
Write a small bit of code using the WSIF API to create the service object from the WSDL and supply it with the stub interface, then use the stub interface ot invoke the service.
The main advantage of this approach is that you (the application) use a high level view of the service (the stub interface).
2. Dynamic invocation:
Write code to access the WSDL, build WSIF messages and operations, and invoke the service.
If by "truly dynamic" you mean you want code to be able to invoke *any* web service, the DynamicInvoker is what you should look at.
In terms of performance issues, DynamicInvoker will be slowly than the other two clients. The stub/dynamic clients will be almost identical in WSIF (stub based will be slightly slower probably), since stub invocation really uses a dynamic proxy mechanism (i.e. under the wraps it really uses the dynamic API, we don't actually generate a hardcoded stub class, just allow access via the stub interface).
Hope that helps,
Nirmal.
| Anuj Agrawal <[EMAIL PROTECTED]>
04/01/2003 12:17 PM
|
To: [EMAIL PROTECTED] cc: Subject: Re: Dynamic Invoker (was Re: SOAP samples) |
Hmm.. i looked at the dynamic clients in the samples. And now i'm
confused (i think). I thought the dynamic clients would be truly
dynamic, but they ALL have references to some kind of generated
beans/stubs (e.g. in the localjava sample, it imports
localjava.client.stub.addressbook.wsiftypes.Address). Is that the
right approach?
I should also explain here that i'm totally comfortable creating static
invocation clients (using WSDL2Java tool to generate stubs etc.). But
for our long term goals, we felt that using DII would be a better way
to go and an article on webservices.org suggested that IBM's (and now
ASF's) WSIF is a good way to go. But then on the java.sun.com's web
services tutorial, they suggest to use DII *only* if the client cannot
use static stubs. The article also suggests that the performance hit
of using DII is not very significant - is this really the case? I
guess it boils down to should we or shouldn't we use DII over static
stubs? (The only article that compares the 2 approaches was the one on
webservices.org.)
Anuj.
--- Nirmal Mukhi <[EMAIL PROTECTED]> wrote:
> The DynamicInvoker is an example of using the WSIF dynamic API to
> invoke
> any web service. If you want to write your own client that uses
> WSIF's
> dynamic API, that code would help. However since the DynamicInvoker
> code
> is used to invoke *any* web sevrice, it does introspection and things
> that
> you would not require if you were just writing a client to access a
> particular web service. You can also look at the dynamic clients in
> all
> the samples. There is no "recommended" way, but hopefully all those
> examples will help.
>
> Anuj Agrawal <[EMAIL PROTECTED]>
> Ok - that clears that up. I see the DynamicInvoker class being used
> as
> well. Is the code in that class the "recommended" way for us to
> build
> web service clients using dynamic invocation?
>
> --- Nirmal Mukhi <[EMAIL PROTECTED]> wrote:
> > WSIF allows stubless (dynamic) invocation as well as invocation
> > through
> > JAX RPC stubs. You don't have to do stub invocation if you don't
> want
> > to.
> > The sample present two alternative clients for accessing the same
> > service,
> > one using the dynamic API and one using a JAX RPC stub (all the
> > samples
> > follow this format).
> >
> > Anuj Agrawal <[EMAIL PROTECTED]>
> > I've been reading up on WSIF and it sounds great! I have a
> question
> > regarding usage.
> >
> > In the SOAP (StockQuote) sample on the ws.apache.org/wsif site, why
> > are
> > (any) stubs are used in the example? I thought one of the main
> ideas
> > of the dynamic invocation was that we wouldn't need to generate
> > stubs.
> > Did i miss something here?
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://platinum.yahoo.com
