Hi Sanoran
As Paul mentioned, this Synapse is the best solution for you. Not only
can it create proxy services at B, but also enforce 2-way SSL between A
and B and, validate or transform requests from A before being forwarded
to C etc.. all *without* coding!
Look at some of the Synapse samples, and Sample #51 would be of
interest to you -
http://ws.apache.org/synapse/Synapse_Samples.html#Sample51
Synapse can handle MTOM, SwA as well as Base 64
You do not have to use Axis2 to "host" Synapse, as it can run
standalone at B. It would be a better implementation to keep your
intermediary running on a separate VM/process if you are using an
instance of Axis2 to host "other" service implementations for your
clients at B anyway. Also, being an intermediary Synapse has to deal
with many concurrent connections - and typically a two way request
through Synapse requires two ports to be open between A-B and B-C. Thus
Synapse runs outside of a typical servlet container to achive a high
throughput, as servlets are blocking. Synapse is designed and developed
to handle this scenario without blocking on IO and is using Java NIO
through the Apache HttpCore/NIO to achieve this. (Check
http://wso2.org/library/1721 for some preliminary figures)
asankha
Sanoran Triamesh wrote:
Thank you for your suggestions. The server at B can have axis2
in it (hence intermidiate web-service that can intercept soap headers
etc). What I am really concerned about is attachments. I expect to have
large attachments, both ways.
Unfortunately I am new to web service and not familiar with
ws-addressing yet, -so its a learning process, -I am trying to create
an intermidate service, and probably have to experiment a bit to see if
it works.
Thanks again,
S
On 7/9/07, Walker,
Jeff <[EMAIL PROTECTED]>
wrote:
The 'standard' web service solution I believe, is to write some SOAP header
handlers, deploy them at B, and they take care of logging, they then
pass the request onto the actual web service impl at C, if certain
required checks pass.
This
is the whole point of SOAP headers, I think. They take care of pre (and
post) processing like logging and auditing, in
your domain. (Doesn't WS-Addressing do something like this?)
Having said that, you have a plain HTTP server at B and not
an intermediate web service that catches all requests (which is what
most SOA architects would recommend, I think). Can the HTTP server have
functionality added to it? Your HTTP server at B should be able to
intercept the HTTP request bound for the web service at C and at least
log the request. This is a fairly basic function of any HTTP server. (I
once had a simliar kind of situation, but in our case, we were using
2-way SSL and the cert had to be extracted, checked and the
request decrypted at the http server, which was forwarded to our web
service).
We are a big defense company and have very restrictive
internet access. I have to create a pc/desktop client (A) to a web
service (C) that inside a isolated lan, and can only access C via an
intermidiate http server (B). Also, I have to log/monitor requests at B
and convince security people that they can intercept/monitor the
requests. I am sure there are many solutions possible, but I am also
new to web services. So my proposal was to have A send a SOAP/http
request to B, where there will be a 'proxy' service that will send the
request to C. Synapse could be an axis service running inside B
redirecting and allowing monitoring.
I would, of course, not want to code anything on B but
rather use an existing solution.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|