Layout's Studying Notes

My studying notes for Java,Ruby,Ajax and other any interesting things.

星期一, 十一月 06, 2006

Fwd: [xfire-user] Calling existing webservice by XFire



Forwarded Conversation
Subject: Calling existing webservice by XFire
------------------------

From: Layout Layout <skyloper@gmail.com>
Date: Tue, Oct 31, 2006 at 2:38 PM

Cause of requirements changed,we have to intergrate with some other system in one of my projects.
And the best way of integration is web service.
After reviewwing serval SOAP framework,we think XFire is our best choice.

But there are still some questions bothering us.
1.Does Client API(http: //xfire.codehaus.org/Client+API) method only run under JDK5 ?
Our development Env. and delopyment Env are both jdk1.4.  What should we do to make
sure that the calling can be done under jdk1.4 ?

2.Can dynamic client method(http://xfire.codehaus.org/Dynamic+Client )
deal with the complex type like POJO ? We have made some test, it seems no.
After calling the GeoIP(at http://www.webservicex.net), it returned a xml document.
How should I make it works with complex type ?


--------
From: Tomek Sztelak <tsztelak@gmail.com>
Date: Tue, Oct 31, 2006 at 4:12 PM

Hi

On 10/31/06, Layout Layout <skyloper@gmail.com> wrote:
> Cause of requirements changed,we have to intergrate with some other system
> in one of my projects.
> And the best way of integration is web service.
> After reviewwing serval SOAP framework,we think XFire is our best choice.
I agree ;)

> But there are still some questions bothering us.
> 1.Does Client API(http: //xfire.codehaus.org/Client+API)
> method only run under JDK5 ?

No, Client api works on java 1.4 also. Only generated clients (
http://xfire.codehaus.org/Client+and+Server+Stub+Generation+from+WSDL
) works only on java 5 ( but you can use Retrotranslator to make it
java 1.4 compatibile ).

> Our development Env. and delopyment Env are both jdk1.4.  What should we do
> to make
> sure that the calling can be done under jdk1.4 ?
>
> 2.Can dynamic client
> method( http://xfire.codehaus.org/Dynamic+Client)
> deal with the complex type like POJO ? We have made some test, it seems no.
> After calling the GeoIP(at http://www.webservicex.net), it returned a xml
> document.
> How should I make it works with complex type ?

Currently dynamic client doesn't work well with complex types, but as
i heard it should change in near future.

>


--
-----
When one of our products stops working, we'll blame another vendor
within 24 hours.

---------------------------------------------------------------------
To unsubscribe from this list please visit:

   http://xircles.codehaus.org/manage_email


--------
From: Layout Layout <skyloper@gmail.com>
Date: Tue, Oct 31, 2006 at 4:22 PM

Thanks for your helpful repy. It encourage me a lot.
 
I read the xfire documentation in the disctribution and it says that xfire can run well under jdk1.4.
 
Well,my next question is how to generate or create the client api without the wsgen tools (task)?
Let me clear it :
"

First you need to create a Service like you do on your server. This provides the metadata about how the service is structured:
Service serviceModel = new ObjectServiceFactory().create(YourService.class);

Next, you'll need to create a proxy for your service:
YourService service = (YourService)
    new XFireProxyFactory().create(serviceModel, " http://your/remote/url");

"
these words are quoted from http://xfire.codehaus.org/Client+API, and who can tell me how to create the interface YourService.class ?
and how about the input/output parameter ?
 
Can complex type can be supported by client api method ?
 
[Quoted text hidden]

--------
From: Tomek Sztelak <tsztelak@gmail.com>
Date: Tue, Oct 31, 2006 at 4:29 PM

You use Client Api when you have access to service java interface and
all classes used by it ( params and results ).  So.. if you have
service MyServiceImpl which implements MyService interface and one of
its methods use MyPojoParam class as parameter you have to have
MyService and MyPojoParam on client if you want to use this API.
[Quoted text hidden]
--
[Quoted text hidden]

--------
From: Layout Layout <skyloper@gmail.com>
Date: Tue, Oct 31, 2006 at 4:36 PM


OK,I see.
Does that mean if I am going to call a web service I have to have the server side API ?

But our client web service maybe was write by domino and C++,is that possible for me to call it using XFire ?

for example,there is one webservice and the wsdl,how can I call it by xfire ?(without the wsgen)
http://www.webservicex.net/MortgageIndex.asmx?WSDL

and we maybe do not know the web service besides the WSDL.

Can I write the client api myself ?
[Quoted text hidden]

--------
From: Tomek Sztelak <tsztelak@gmail.com>
Date: Tue, Oct 31, 2006 at 4:49 PM

On 10/31/06, Layout Layout <skyloper@gmail.com> wrote:
>
 > OK,I see.
> Does that mean if I am going to call a web service I have to have the server
> side API ?
>
> But our client web service maybe was write by domino and C++,is that
> possible for me to call it using XFire ?
>
> for example,there is one webservice and the wsdl,how can I call it by xfire
> ?(without the wsgen)
> http://www.webservicex.net/MortgageIndex.asmx?WSDL

If you want to use client based only on service wsdl you must generate
client code ( using wsgen ). This code will work only on 1.5, but as
mentioned earlier, you can convert this to java 1.4 with
retrotranslator.
[Quoted text hidden]
--
[Quoted text hidden]

--------
From: Layout Layout <skyloper@gmail.com>
Date: Tue, Oct 31, 2006 at 6:55 PM

thank you very much.

I tried to write a service class by hand and call the web service ,but I failed.It always report that emply SOAPAction can not be recogenize by the server.(I am using .net web service)。

I like xfire,but it seems that I have to use some other framework to calling the existing web service which created in C++(because having no java APIs).

I can use xfire to create web service well.
[Quoted text hidden]

--------
From: Skyloper Dan <skyloper@gmail.com>
Date: Wed, Nov 1, 2006 at 11:03 AM

After discussing with Tomek Sztelak,I write a script to generate the stubs for WSDL,and translate to jdk1.4.
But unluckly,I can not run the testCase in eclipse . It reported that :
java.lang.UnsupportedClassVersionError : org/codehaus/xfire/annotations/jsr181/Jsr181WebAnnotations (Unsupported major.minor version 49.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
at java.net.URLClassLoader$1.run (URLClassLoader.java:194)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at net.webservicex.geoip.GeoIPServiceClient.create0 (GeoIPServiceClient.java:57)
at net.webservicex.geoip.GeoIPServiceClient.<init>(GeoIPServiceClient.java:26)
at org.layout.xfire.client.GeoIPClient.testGetGeoIP(GeoIPClient.java:9)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke (Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected (TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run (TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main (RemoteTestRunner.java:196)


And here is my ant script and testcase.
build.xml
-----------------------------------------------------------------
<?xml version="1.0" encoding="gb2312"?>

<project name="wsdl_gen" default="main" basedir=".">
<property environment="env"/>
<property file="build.properties" />

<path id=" compile.classpath">
<fileset dir="${basedir}/lib" includes="*.jar" />
</path>

<taskdef name="wsgen" classname="org.codehaus.xfire.gen.WsGenTask" >
<classpath refid="compile.classpath"/>
</taskdef>

<taskdef name="translator" classname="net.sf.retrotranslator.transformer.RetrotranslatorTask">
<classpath refid=" compile.classpath"/>
</taskdef>
<target name="init">
<delete dir="${dir.target}" />
<mkdir dir="${dir.target}" />
</target>

<target name="main" depends="init">
<wsgen
outputDirectory="${dir.target}"
wsdl="${dir.wsdl}/${source.wsdl.name}"
package="${target.package.name}" overwrite="true"/>
<antcall target="compile.java " inheritall="true"/>
<antcall target=" compile.jar" inheritall="true"/>
<antcall target="translate.jar"/>
<antcall target="clean"/>
</target>

<target name="compile.java"
description="compile the java sources and copy associated resource files">
<delete dir="${dir.build}"/>
<mkdir dir="${ dir.build}"/>
<javac srcdir = "${ dir.source}"
destdir = "${dir.build}"
debug = "${compile.debug}"
deprecation = "${compile.deprecation}"
optimize = "${ compile.optimize }">
<classpath refid="compile.classpath"/>
</javac>
</target>
<target name="compile.jar">
<mkdir dir="${dir.dest}"/>
<mkdir dir="${ dir.build}/META-INF/"/>
<copy todir="${dir.build}/META-INF">
<fileset dir="${dir.source}/META-INF" />
</copy>
<jar destfile="${dir.dest}/${ target.jar.name}">
<fileset dir="${dir.build}" />
</jar>
</target>
<target name="clean">
<delete dir="${dir.build}"/>
<delete dir="${ dir.source}"/>
</target>
<target name="translate.jar">
<translator srcjar="${dir.dest}/${ target.jar.name}"
destjar="${ dir.dest}/${target.1.4.jar.name}"
verify="true"
>
<classpath location="${java14_home}/jre/lib/rt.jar"/>
<classpath refid=" compile.classpath"/>
</translator>
</target>
</project>
----------------------------------------------------------------------
test case
---------------------------------------------------------------------
package org.layout.xfire.client;

import net.webservicex.geoip.GeoIPServiceClient;
import net.webservicex.geoip.GeoIPServiceSoap ;
import junit.framework.TestCase;

public class GeoIPClient extends TestCase {
public void testGetGeoIP() {
GeoIPServiceClient service = new GeoIPServiceClient();
GeoIPServiceSoap geoIPClient = service.getGeoIPServiceSoap ();

System.out.println("The country is: "
+ geoIPClient.getGeoIP("216.73.126.120").getCountryName());
}

}

----------------------------------------------------------------------------------------------
Who can tell me ho to run it ?
[Quoted text hidden]

--------
From: Tomek Sztelak <tsztelak@gmail.com>
Date: Wed, Nov 1, 2006 at 7:26 PM

As i understand, retrotranslator converts only generated classes, but
xfire annotation jar still use java5. So you probably need to
translate also xfire-annotation.jar.
[Quoted text hidden]
--
[Quoted text hidden]

--------
From: Andres Bernasconi <andres.bernasconi@gmail.com>
Date: Thu, Nov 2, 2006 at 4:35 AM

I am using XFire with 1.4 and don't have any problems. I don't even care what the web service implementation is. I just "invent" a Java Interface in my client that adheres to the WSDL contract. I also create any necessary objects, (unless I can reuse some of my existing objects, which I did some times). For all this I am integrating XFire with Spring and using Aegis mapping, because I HATE generated classes and cumbersome steps in my builds. I do have complex types, including Map's and Array's of Map's. Everything is working perfectly, although I do not know if it will work with .net (because of the SoapAction thing, I belive .NET does not implement the specification correctly in that case. I've seen a similar post on this forums some time ago)

Best of Lucks,
Andres Bernasconi
[Quoted text hidden]

--------
From: Skyloper Dan <skyloper@gmail.com>
Date: Thu, Nov 2, 2006 at 9:40 AM

To Tomek Sztelak:
I tried to translate the jar you said,but it can not be translated.Many depences can not be found.
To Andres Bernasconi:
Yes,the all the web services but .NET.
I "invent" the client api according to the examples in the XFire1.2.2 distrubution,and it can run fine with 1.4,but when calling the web service(.NET),It reported the SOAPAction is empty.
 
I have to use axis1(wsdl2java) to generate stub and call the service,and it works fine.
btw,I think axis2 has many problems,even the documentation.

 
[Quoted text hidden]

--------
From: Taras Puchko <taras.puchko@gmail.com>
Date: Thu, Nov 2, 2006 at 5:53 PM

Hi!

To make generated XFire client work on JRE 1.4 all modules can be
translated with Retrotranslator to fully eliminate Java 5 API usages.
The module dependencies should be provided via -classpath ONLY if
verification is enabled, since they are not used during the
translation. Setting -Djava.class.version=49.0 property when running
client can also help in case of problems with type mapping.

I am the author of Retrotranslator.

Regards,
Taras
[Quoted text hidden]

--------
From: Tomek Sztelak <tsztelak@gmail.com>
Date: Thu, Nov 2, 2006 at 6:04 PM

Hi Taras
Did run translated XFire client succesuly ? If so, maybe you can write
few words what must be done ? :)
[Quoted text hidden]
--
-----
When one of our products stops working, we'll blame another vendor
within 24 hours.

---------------------------------------------------------------------
[Quoted text hidden]

--------
From: Taras Puchko <taras.puchko@gmail.com>
Date: Thu, Nov 2, 2006 at 6:31 PM

I did it almost half a year ago, but AFAIR I had successfully run both
a Java 5 server and a generated Java 5 client on JRE 1.4. Both of them
were using annotations and generics. I translated them along with
XFire, like this:
java -jar retrotranslator-transformer-1.0.9.jar -srcjar server.jar
-srcjar client.jar -srcjar xfire-all-1.2.2.jar
And at runtime I specified -Djava.class.version=49.0 both for the
client and the server:
java -Djava.class.version=49.0 -jar client.jar
This was needed especially on the server for generic collections to be
correctly exposed via autogenerated WSDL, since XFire sometimes does
not use generics and annotations if this option is 48.0.
[Quoted text hidden]

--------
From: Andres Bernasconi <andres.bernasconi@gmail.com>
Date: Sat, Nov 4, 2006 at 12:00 AM

Tomek,

going back to the .NET issue, is there any way to configure XFire to be able to talk to .NET services? Even if it does not follow the spec, I believe being able to connect to .NET will give a bigger user-base to XFire, something we will all benefit from.

Regards¿
AB
[Quoted text hidden]

--------
From: Tomek Sztelak <tsztelak@gmail.com>
Date: Sat, Nov 4, 2006 at 12:10 AM

Yes, it possible and lot of ppl do it :)
But you must use client which use annotations,  so XFire will be able
to fill SOAPAction field.
[Quoted text hidden]
--
-----
When one of our products stops working, we'll blame another vendor
within 24 hours.

---------------------------------------------------------------------
[Quoted text hidden]

--------
From: Andres Bernasconi <andres.bernasconi@gmail.com>
Date: Sat, Nov 4, 2006 at 6:34 AM

Oh, i see... pitty me :)
[Quoted text hidden]

--------
发帖者 时间：

没有评论:

发表评论

订阅： 博文评论 (Atom)