Super - thanks.
Benson Margulies wrote:
The answer to your questions is "yes".
On Mon, Aug 17, 2009 at 12:51 AM, Demetris<demet...@ece.neu.edu> wrote:
Hi Benson,
I took a look into the rt folder and did go over the cxf-utils.js module -
so the generated
client javascript code makes use of this module to send its requests to the
service - correct?
I know that looking through the code is the best way to learn a lot of this
but this code
is fairly large so I am not sure I will have the time to go through it
before I need to make the
decision to go with CXF - the only Q I have here is, before I invest the
time going over the
documentation, is there enough material there to help me figure out CXF? It
seems that the
web site if fairly well organized so that's encouraging.
Thanks
Benson Margulies wrote:
I would recommend wrapping/intercepting the object in cxf-utils.js
that sends the requests.
There's really no substitute for reading some of this code.
On Fri, Aug 14, 2009 at 12:07 PM, Demetris<demet...@ece.neu.edu> wrote:
So if I want to intercept the SOAP message that the client javascript
will
be sending out I will need
to dig into the http layers? Is there anything I can do at the app layer
to
intercept that message without
disrupting/modifying the javascript?
Benson Margulies wrote:
When the server provides the javascript, it provides the correct URL.
Which is often not port 8080.
To answer another question, no z/OS is not required.
On Thu, Aug 13, 2009 at 4:57 PM, Demetris<demet...@ece.neu.edu> wrote:
One more question for whoever has a few minutes to help out -
Let's say my client contacted the remote server using a URL in order to
obtain the javascript client.
When this script is loaded and ran on the client side browser, I am
assuming
that by default it uses
HTTP to send out the SOAP message to the server right? Which port does
it
write to - similar to
Axis, 8080?
Demetris wrote:
Hey guys,
the documentation says:
"It is relatively straightforward to run a CXF service in a Tomcat
<http://tomcat.apache.org/> container on z/OS". But the IBM OS
is not a requirement correct? I can run this service on any Tomcat
container running on any OS right?
I know this is an elementary Q but I wanted to make sure there are not
OS-specific dependencies.
Thanks
Benson Margulies wrote:
CXF has two things going on here.
1) you can ask the server to generate and deliver the javascript
client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.
However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.
On Wed, Aug 12, 2009 at 4:47 PM, Demetris<demet...@ece.neu.edu>
wrote:
Does CXF support client-side programming for Web Services? What we
are
after
in one of our projects
is to:
(1) host web services (or at least a Soap engine) on mobile devices
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by
discovering
and
utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate
the
client code.
Not sure how realistic this is at this stage but I am not finding
much
on
(1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult
task
so
we
are considering the off-the-
device mechanisms.
Daniel Kulp wrote:
On Tue August 11 2009 11:26:05 pm Demetris wrote:
Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.
I believe Axis1 can do doc/literal. JAX-RPC did require some
level
of
support for that so I'm pretty sure Axis1 implemented it. Not
sure
how to
go about configuring it to do so. I'm not an Axis1 user. :-)
Dan
Benson Margulies wrote:
Demetris,
If your place has a big investment in RPC/encoded, perhaps one of
you
would like to pick up the project that one of our committers
started
of adding RPC/encoded support to CXF. If you do it, you get to
ensure
that it works with your services :-). I'd be happy to mentor
someone
in figuring out where Dain left off.
--benson
On Tue, Aug 11, 2009 at 4:21 PM, Demetris<demet...@ece.neu.edu>
wrote:
Of course I do see infrastructures here in production still
using
Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc.
and
interoperability between the
two sides is impossible - and of course the rest of us will need
to
sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a
feeling
I
will be adapting it to my
work.
Cheers
Daniel Kulp wrote:
On Tue August 11 2009 12:15:40 pm Demetris wrote:
That's what I figured ;) Thanks for the info Benson.
Now regarding inteconnection of Web Services across
implementations,
if there is no bridge
between the old RPC/encoded and CFX, at least I am assuming
that
newer
versions would
be able to handle SOAP calls across them or not? This is
something
I
never tried/looked into
while I worked exclusively with Axis so I was wondering.
Pretty much none of the modern SOAP toolkits support
RPC/encoded.
Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't.
Etc....
Basically, rpc/encoded was such an interopability nightmare
that
it
really fell into the bucket of "You REALLY REALLY don't want to
use
it." If you want interopability, you really need to migrate
to
one
of the literal forms.
Dan
Benson Margulies wrote:
OK, that message is buried in the substrate somewhere. I'm
not
sure
that I agree with it :-) In practical terms, we just don't
have
the
code or RPC/encoded.
I'm unaware of anything you can use to interconnect an old
Axis
RPC/encoded service with CXF.
On Mon, Aug 10, 2009 at 11:00 PM,
Demetris<demet...@ece.neu.edu>
wrote:
Hi Benson,
the reason I mentioned JAX-WS is because a WSDL file that I
passed
to WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a
feeling
it
is "neither here nor
there" but I wanted to double-check - I think I know what
the
issue
is now after reading the
corresponding documentation but I will return and send more
info
if
I cannot resolve it.
A separate question - is there a "bridge" between Axis WS
and
its
tools and CFX? Can an Axis
WS client call a CFX-implemented WS and vice versa or not?
Thanks
Benson Margulies wrote:
Demetris,
CXF includes the ability to build Soap 1.1 Javascript
clients
for
doc/lit and rpc/lit services. JAX-WS is relatively neither
here
nor
there.
The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility
file
supplied) will run anywhere that has a compatible request
object.
Or, you can ask any CXF-implemented web service to deliver
a
javascript client, and one will be returned.
Have you read
http://cwiki.apache.org/CXF20DOC/javascript-clients.html?
--benson
On Mon, Aug 10, 2009 at 5:40 PM,
Demetris<demet...@ece.neu.edu>
wrote:
And one more observation - because wsdl2js utilizes JAX-WS
2.0,
RPC/Encoded
documents are not supported. Is that correct?
Thanks again
Demetris wrote:
Ok now that I played a bit with wsdl2js I am beginning to
understand what
you said below.
So one can use the wsdlurl in order to get the server to
return
the script
- can you please
clarify a few things since I am new to this -
1. what kind of server are we talking about in this case?
2. The only way to generate the Javascript is through a
remote
server
+ URL? If I have the WSDL
in my possesion how can I use this tool to generate the
script
of
me?
Thanks again
Benson Margulies wrote:
The tool is part of CXF, so it requires Java 1.5. Since
its
output is Javascript, I don't understand why you need to
run
it
under J2ME.
In fact, you can just use the ?js URL form from the
server
to
get the server to generate it on the fly.
On Mon, Aug 10, 2009 at 2:32 PM,
Demetris<demet...@ece.neu.edu>
wrote:
Hi all,
I am interested in generating Javascript stubs from a
WSDL
file - I am
assuming that the WSDL2js tool is the
appropriate tool to use. Has anyone used this tool so
that
I
can ask a couple of Qs?
(1) Which Java version is the tool built on?
(2) Can I used it under J2ME-CDC to generate stubs for
mobile
devices?
Thanks in advanced
