And a Q for the Axis folks (1.4) which triggered some of the discussion
below.
Taking a look at the architectural view of Axis 1.X
(http://ws.apache.org/axis/java/architecture-guide.html)
it shows that the Axis Engine actually also runs on the client side and
not only on the server side.
But a lot of folks are telling that is not necessary. Can someone
clarify this for me please? Am I reading
the schematics in there the wrong way ? It will make a difference on how
I will be monitoring outgoing
traffic depending if I will be looking at an Axis Engine versus
generated client stubs.
Thanks very much
Demetris G wrote:
Will do - thanks Rich, Martin and Glen for all the information you
provided. I appreciate it.
I am currntly working with Axis 1.4 for the particular application I
am monitoring so I think
the generals ideas below apply there as well (not just Axis2).
What we set forth to do was to be able to read everything sent out of
any Axis 1.4 generated
stubs as they execute to call remote (web) services without needing
to modify the source of
those stubs (meaning to let the corresponding tools generate them as
they would originally).
Eventually I am hoping to be able to introduce similar functionality
to what the tools below do
in a more automated fashion inside some kind of a middleware. I am
not sure how much of
that would reinvent the wheel but I am sure it will be pretty
educational :)
Anything more that you guys can add from your experiences would be
greatly appreciated.
Thanks again
Martin Gainty wrote:
Hi Demetris
Take a look at the tutorial located here
http://ws.apache.org/commons/tcpmon/tcpmontutorial.html
you can either redirect OR set it up as a proxy (so it catches all
traffic..be aware there is alot of traffic for IP:Port)
M--
This email message and any files transmitted with it contain
confidential
information intended only for the person(s) to whom this email
message is
addressed. If you have received this email message in error, please
notify
the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.
----- Original Message ----- From: "Demetris G" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, May 21, 2007 8:44 PM
Subject: Re: Simple Qs
Glen - do you know how I can find out on which port the client
stubs attempt to
write to? What determines that? I am assuming the code generating
tools
read some kind of a configuration before they can attach a port to
write out
to? I am referring to the client side. Which outgoing port do the
stubs choose
to write on?
Thanks much
Glen Mazza wrote:
Probably, but I really don't know much about the Axis 1.x series.
Glen
Am Montag, den 21.05.2007, 19:05 -0400 schrieb Demetris G:
Hi Glen,
thanks for the info. I am assuming the same applies for Axis
1.4?
Thanks
Glen Mazza wrote:
Am Montag, den 21.05.2007, 17:19 -0400 schrieb Demetris G:
I may be reading the overall Axis architecture a bit
differently but I have these Qs if anyone can
help -
During a Client application call to a remote Axis engine ( SOAP
call generated by the corresponding
Client stubs), does an Axis engine need to be running on the
client side or do the stubs contain
the necessary information to generate the SOAP call and contact
the remote Axis engine.
The latter. The Axis2 engine is a WAR file that runs on a Servlet
container. The web service is packaged as a service archive
(.aar file)
and is placed in the WEB-INF/services directory of the exploded WAR
file. You client makes (usually) HTTP requests to access the web
service, but the Axis engine is not needed for that.
In other
words, if I am sitting on the client side, where should I be
looking at to capture the outgoing SOAP
message leaving a particular application?
If you wish to capture the message sent by the client, Apache
TCPMon may
be of help for you:
http://ws.apache.org/commons/tcpmon/tcpmontutorial.html
Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
