I am not very focused on my web services task at the moment as my duties don't allow me to, but nevertheless - can you please help me understand just how can one implement this 'simple' scenario.
CLIENT ---> INTERMEDIARY ---> ENDPOINT
Many clients will connect with different "payload weight", so if client A chokes (the computation lasts say 1 minute) the ENDPOINT where the actual work is done, all other clients, which were unfortunate to request the service for just a few seconds after the client A, will have to wait and that is undesirable. The intermediary would have to implement load balancing and queues, but that is not what I am afraid of (or should I be?).
My first goal would be just simply the intermediary to receive the request, read the headers, make some database operations, make some choices and if everything is ok, forward the request with new headers to "real" web service (ENDPOINT) to do the job. If successful, the intermediary again does some processing and returns the result back to the originator of the request - the CLIENT.
Now, what happens if in the middle of this process another request comes in? The intermediary should be clever enough to know that the ENDPOINT is busy and act accordingly. I read about synchronous and asynchronous requests and other theoretical stuff which I could find on the internet, but I am still confused. If asynchronous services would be a way to go, then I guess the clients will have to be smarter and the choice of technology narrower. If request-response mechanism could do the job, it would be easier, wouldn't be?
I am aware (it is even a demand) that I will have to implement several ENDPOINTs which would work as a farm of the same services to increase the efficiency and the reliability of service will be one of the major questions, so I don't want to start implementing a bad architecture which will limit my options later on.
I have written a client which I installed on several machines to stress test the ENDPOINT web service. I bombarded the poor workhorse from those machines with requests coming apart just under a second from each. Each response lasted roughly from 15 to 45 seconds, but they all got processed successfully. Now, I would be a happy person if I could be able to squeeze this intermediary in-between to do some logging.
I am developing with Java and WebObjects as the application server, just to note. WO uses Axis engine.
Regards, bob
On Thursday, Oct 23, 2003, at 18:34 Europe/Ljubljana, Anne Thomas Manes wrote:
Note that WS-Addressing supercedes WS-Routing/WS-Referral. See http://www-106.ibm.com/developerworks/webservices/library/ws-add/
The technical name for this mediator is a SOAP Intermediary.
Most Web Services Management products operate as SOAP intermediaries -- executing as a proxy to the target Web service. These intermediaries can execute as a separate SOAP node or as a servlet which filters the request. The way most of these products work is that they set the WSDL endpoint address to point to the URL of the intermediary. The intermediary does its processing and then forwards the request (via a separate SOAP invocation) to the actual Web > service.
Another alternative is to use SOAP headers to manage the message path -- in which case you want to use the SOAP header blocks and processing model defined by WS-Address or the older WS-Routing.
Anne
At 09:22 AM 10/23/2003, you wrote:As a matter of fact, you don't need this kind of "mediator". It is WS-routing/WS-forwarding/WS-refering all about.
-Henry
From: "Rodrigo Ruiz" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: <[EMAIL PROTECTED]> Subject: Re: WebServices chaining Date: Mon, 13 Oct 2003 12:48:10 +0200
If you want this mediator to act as a server, you will probably implement it
as another "higher-level" web service. This means it will be deployed on a
tomcat server, or similar.
In this scenario, requests will be served in different threads, so you could
let the virtual machine to handle the dispatching ;-)
If you need some kind of serialization, so you do need to execute all local
processing in a single thread, I guess you will have to implement your own
dispatcher to handle them.
If you do not really have the necessity of serializing all the processings,
I recommend you to use simple synchronization instead, and let the JVM do
the hard work for you. On the other hand, if you need transactional
processing, maybe your best option would be to implement it on session EJBs,
and let the EJB container deal with all that stuff.
Hope it helps, Rodrigo Ruiz
----- Original Message ----- From: "Borut Bolcina" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 13, 2003 7:46 AM Subject: WebServices chaining
> Hello.
>
> I have just finished reading theory at some web sites concerning Web
> Services talking to each other. Although I got some insight, it would
> be great if someone has experience or even some guidelines to kick
> start me. Lots of fog everywhere.
>
> I have successfully implemented clients and server, but I must
> implement a "mediator" - something that acts as server and client. This
> mediator does some processing and forwards the request to another web
> service. When the response is generated the mediator gets it, does some
> further processing and returns the response to the originator of the
> request - the original client.
>
> I guess this is not too hard to do, is it? The requests will be coming
> in "hopefully" at short intervals, but the response time varies from
> seconds to a minute. Obviously the responses won't be served on a FIFO
> basis. Will I have to manually "bind" the right requests with the right
> responses and what is there for me to identify them uniquely OR is
> there a mechanism that does this for me - some kind of dispatcher?
>
> I will appreciate some guidance very much.
>
> I wish you a nice and successful day!
>
> --bob
>
_________________________________________________________________
Fretting that your Hotmail account may expire because you forgot to sign in enough? Get Hotmail Extra Storage today!
http://join.msn.com/?PAGE=features/es
