Dynamic Webservices Client

Question

Hey ,
I have an application which requires to talk to 2 different published webservices
from 2 different systems. Now instead od designing static webservice clients for
each of these systems(which would involve having separate proxy jars etc),
I am planning to design a dynamic webservice locator and invoker....
I know that we can have webservice clients which are dynamic to the extent that
we can create proxy objects at runtime once we know the endpoint WSDL..
eg:
ServiceFactory factory = ServiceFactory.newInstance();
QName serviceName =new QName targetNamespace,"net.xmethods.services.stockquote.StockQuoteService");
QName portName = new QName(targetNamespace,"net.xmethods.services.stockquote.StockQuotePort");
QName operationName = new QName("urn:xmethods-delayed-quotes","getQuote");
URL wsdlLocation = new URL("http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl");
// create service
Service service = factory.createService(wsdlLocation, serviceName);
// create call Call call = service.createCall(portName, operationName);
My question on this...if I have a dynamic approach like the above what are the
pros and cons..I guess it would surely have more overhead compared to a static
client...?
Secondly ,is it even feasible to design a dynamic client in such a way that the
endpoint WSDL could also be an unknown and my generic client would also locate
the end-point dynamically and then invoke dynamic calls as above...
If anybody can share their insights on a dynamic webservice client , I would really
appreciate it...
Thanx,
Krish
KRISH.VENKATARAMAN
Senior Technology Analyst
Bank of America Corp.
Email:[email protected]

Answer 1

Hi Krish,
In WSDL, the data types passed between applications are described in schema
and
this is key for interop. I dont know of any standard/natural mapping for
values types,
object reference, etc in a binary protocol (like JRMP, IIOP) to schema. For
eg:
say there is serializable object Foo, which is the argument to a remote
method in RMI.
Object Foo can have data + behavior. It may be possible (not always, i
think) to
describe the data in Foo as schema, but how can one describe the behavior?
So, if WSDL is the only contract between the server and client (key
requirement
for interop), then IMHO RMI can not be described by WSDL.
Also, WSDL was designed for future extensions and does not map well to a
programming API. WSIF trys to expose all the gory WSDL details and its apis
are very clumsy.
These were the two main reason to vote it down at JAX-RPC EC.
I am attaching an example that shows, how to introspect WSDL and invoke
a method using JAX-RPC (with little extension to the std api). Also, it
shows
how to handle complex type without data binding. Will this solve your
problem?
I am very interested to get your feedback on this.
BTW, This example will only work with WLS 8.1.
regards,
-manoj
"Krish Venkataraman" <[email protected]> wrote in message
news:[email protected]...
>
>
Mike...thanx for the inputs...
As per ur suggestion...I have taken this offline and mailed u [email protected]
also....lemme know if thatz cool...
there are my observations..lemme know what am i missing..
1) The main difference I see between JAX-RPC and WSIF, is that with WSIFclient
it is easier to port to services talking
via other ports like RMI,IIOP etc...where as JAX-RPC is understandsonly SOAP(atleast
for now).
2) Lets assume for the time-being that I would be interested only to talkto services
talking SOAP.
Then why do I need WSIF ?
3) I can have a JX-RPC client , I can have a similar generic(reflection)code
for built-in/primitive datatypes and for
complex datatypes I anywayz would be doing the same thing(requiringthe java
representation of the datatype unless I use
something like JROM or something which I do not want to) in JAX-RPC orWSIF.
>
4) As far as syncronous or asyncronous invocation is concerned , myunderstanding
is that my client call is going to remain the
same ..the service provider is going to either use message-oriented orRPC
on his side...
Again assuming that I am interested only with services talking SOAP, thiscould
be my generic client invocation design
Background is that my client is going to run from within a WLS70sp1
Actors:
a) webSevice1ClientSessionBean : This will be a stateless session beanwhich might
have knowledge about webSevice1's end-point ,
complex dataTypes if any.
(There would be other session beans like this which would haveknowledge about
other specific webservice)
b) GenericWebServiceInvoker : This will have knowledge about everythingwithin
the webservice-standards/protocols.
eg:
//set weblogic ServiceFactory
System.setProperty( "javax.xml.rpc.ServiceFactory",
"weblogic.webservice.core.rpc.ServiceFactoryImpl" );
//create service factory
ServiceFactory factory = ServiceFactory.newInstance();
//define qnames
String targetNamespace = "http://soapinterop.org/";
QName serviceName = new QName( targetNamespace, "SimpleTest" );
QName portName = new QName( targetNamespace, "SimpleTestSoap" );
QName operationName = new QName( "http://soapinterop.org/",
"echoStruct" );
//create service
Service service = factory.createService( serviceName );
TypeMappingRegistry registry = service.getTypeMappingRegistry();
TypeMapping mapping = registry.getTypeMapping(
SOAPConstants.URI_NS_SOAP_ENCODING );
mapping.register( SOAPElement.class,
new QName( "http://soapinterop.org/xsd", "SOAPStruct" ),
new SOAPElementCodec(),
new SOAPElementCodec() );
//create call
Call call = service.createCall();
//set port and operation name
call.setPortTypeName( portName );
call.setOperationName( operationName );
call.addParameter( "inputStruct",
new QName( "http://soapinterop.org/xsd", "SOAPStruct" ),
ParameterMode.IN);
All parameter values specific to a particular webservice likeQName,targetNameSpace
etc will be sent to this invoker by
webSevice1ClientSessionBean. The GenericWebServiceInvoker will invokethe
service
(using reflection for primitive/builtin types) and alwayz accept anobject
from the service operation and just return
that "object" back the webSevice1ClientSessionBean.ThewebSevice1ClientSessionBean
will know how to interpret the
complexdataType or builtInDatatype whichever is returned.TheGenericWebServiceInvoker
will not have any application
specific knowledge...it will just have knowledge about how todiscover, invoke
any SOAP webservice...
Somewhere in the beginning of GenericWebServiceInvoker I will use JAXRto
discover services from UDDI if needed.
This way I will have a generic webservice client invocation frameworkwhich
can invoke any service which talks SOAP.
Now lemme know how the above picture looks and what is missing...
I have some questions :
1) Incase of complex dataTypes, I will have itz XML representation inthe
publisher's WSDL and the publisher will give
me the java representation of the complex dataType.But how does myclient
JAX-RPC know how to map the XML
to the java representation unless I specify the mapping somewhere?Does
the TypeMapping/TypeMappingRegistry do this ?
Thanx,
Krish
"Michael Wooten" <[email protected]> wrote:
You know, it's really cool to hear guys thinking things through, before
they "jump
on a bandwagon" :-)
Anyway, I suspect that the performance overhead of doing reflection,
and heavy
server-side code intrusion, is what has made a lot of developers balk
at using
WSIF. I would check out the IBM newsgroups, to see what the general
developer
sentiment is on WSIF.
To achieve any sort of decent performance with JAX-RPC based webservices,
you
need to do a fair amount of optimization/tuning on both the client and
server
side. I recommend setting up your own "lab environment" for doing these,
so you
can see exactly what's making things improve/degrade. If you are really
interested
in this topic, we should talk about it "off-line".
In general, the more "dynamic" things are on the client side, the slower
things
will be, the more you really need to question if you really need them
to be dynamic
:-) Does making it "dynamic" really offer something that you can't get
from a
"static" version? If not, who's really benefiting here. I mean, com'n.
All you
really want to do is invoke an operation, right? By the time you get
all the information
it takes to do a dynamic invocation (i.e. port, target namespace, data
type for
input argument, serializer/deserializer for each non-built-in data type,
etc.),
your client looks like you are trying to boot a PDP-11! LOL! For those
of you
who don't know what a PDP-11 is, it's an early computer (from the'60-'70),
that
you actually had to use switches to create the "binary instructions"
to boot it
up!
From a PM's (product manager's) perpective, I wouldn't even let thedevelopers
modify "working" EJBs to expose them as a web service. Alarm bells should
go off
in your head, if you have to modify existing server-side code to expose
a company
asset as a web service.
Response to OT comment: WebLogic Server 7.0 uses its own implementation
of JAX-RPC
1.0. This implementation, I've been told by one of the BEA engineering
that worked
on it, has been certified to be JAX-RPC compliant by Sun. Don't know
about Apache
Axis, in this regard. I use both Apache Axis and the JWSDP with WLS 6.1,
but I
haven't really spent a lot of time looking for differences between our
(BEA's)
implementation, and theirs.
Regards,
Mike Wooten
"Krish Venkataraman" <[email protected]> wrote:
Hey Mike ...
I hear ya..and I see the significance of WSIF...but that IBM started
it a year
back and itz not yet stabilized is what is holding me back...
U mite have a better hold of what WSIF can do...whatever I could grasp
from yesterday
is this...
a)It reads meta data from the wsdl and using a reflection mechanismcalls
the
service operations...
I see examples with primitive datatypes..but what happens when
complex/custom
datatypes come into play...
Would the client code differ between synchronous invocation toasynchronous
invocation...
And aleast in the samples for the WSIF distribution for connectors like
EJB/JMS
etc, the code does not look generic anymore..there are specific calls
to operations
and parameters...
Also Mike , what is the trade-off on performance between having adynamic
client(lets
say based on WSIF)or having a static client...the extent of reflection
a dynamic
client will have to do and create SAAJ objects at runtime will beenormous..
Also I know that there is a relevant API...but can u give an examleshowing
me
how I could discover services from UDDI ..?
Out of this current topic...does BEA use itz own implementation of SOAP
in itz
webservice implementation...and how does it compare with AXIS ?
Thanx,
Krish
"Michael Wooten" <[email protected]> wrote:
Hi Krish,
Well, I guess that's how things are when "needed functionality exceeds
the current
state of a technology" :-)
I (not necessarily BEA) look at it like way:
1. IBM co-authored the "Big 3" XML grammars for the current web
services
stack.
2. IBM always appears to be "there, somewhere" in the new crop ofproposed
additional
XML grammars for "partially agreed upon extension layers", for theweb
services
stack.
3. IBM donated it's original SOAP implementation to the open-sourcecommunity.
4. IBM came up with WSIF over a year ago.
5. IBM's WSTK uses the Apache Axis stuff.
6. A lot of the JAX-RPC/JAXM API is based on the Apache SOAP and Apache
Axis implementations.
7. It looks like IBM may have donated WSIF to Axis.
8. You appear to need something like WSIF :-)
So, there's probably at least a 60/40 chance that some WSIF-like thing
will make
it into the JWSDP, right? If you want "higher odds", you should talk
to the folks
working on the JWSDP, as they are somewhat "in charge" here :-)
Regards,
Mike Wooten
"Krish Venkataraman" <[email protected]> wrote:
Yes...I am surely lookin at something similar...but that framework
not
being standardized
scares me as I have seen many good ideas not seeing the light of the
day...and
I do not want to design something using a framework which might remain
un-standardized..
what are ur thots..
Thanx,
Krish
"Michael Wooten" <[email protected]> wrote:
Hi Krish,
It sounds like you want WSIF :-)
"WSIF allows stubless or completely dynamic invocation of a Web
service,
>>>>>>
based upon examination of the meta-data about the service at runtime.
It
also allows updated implementations of a binding to be plugged intoWSIF
at
runtime, and it allows the calling service to defer choosing a
binding
until
runtime."
Correct?
This is a relatively new "unofficial" addition to the Web ServicesStack,
so it
is not in WLS 7.0 (or Sun's JWSDP) yet. See the following link formore
details:
http://xml.apache.org/axis/wsif
Regards,
Mike Wooten
"Krish Venkataraman" <[email protected]> wrote:
Hey ,
I have an application which requires to talk to 2 different
published
webservices
from 2 different systems. Now instead od designing static webservice
clients for
each of these systems(which would involve having separate proxyjars
etc),
I am planning to design a dynamic webservice locator and invoker....
I know that we can have webservice clients which are dynamic tothe
extent
that
we can create proxy objects at runtime once we know the endpoint
WSDL..
eg:
ServiceFactory factory = ServiceFactory.newInstance();
QName serviceName =new QName
targetNamespace,"net.xmethods.services.stockquote.StockQuoteService");
>>>>>>>
QName portName = newQName(targetNamespace,"net.xmethods.services.stockquote.StockQuotePort");
>>>>>>>
QName operationName = newQName("urn:xmethods-delayed-quotes","getQuote");
>>>>>>>
URL wsdlLocation = newURL("http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl");
>>>>>>>
// create service
Service service = factory.createService(wsdlLocation, serviceName);
// create call Call call = service.createCall(portName,
operationName);
>>>>>>>
>>>>>>>
My question on this...if I have a dynamic approach like the abovewhat
are the
pros and cons..I guess it would surely have more overhead comparedto
a static
client...?
Secondly ,is it even feasible to design a dynamic client in such
a
way
that the
endpoint WSDL could also be an unknown and my generic client wouldalso
locate
the end-point dynamically and then invoke dynamic calls as above...
If anybody can share their insights on a dynamic webservice client
I would really
appreciate it...
Thanx,
Krish
KRISH.VENKATARAMAN
Senior Technology Analyst
Bank of America Corp.
Email:[email protected]
[BrowserClient.java]
[DynamicClient.java]