Dispatching requests.

[infectedrhythms]

OK maybe I was asking this wrong!? :?

How would I dispatch requests from one servlet to multiple "components" remotly.

The servlet will act as a signle point of access to the rest of my systems.... Based on the xml my servlet will dispatch/forward the the requests to the appropriate systems localy and or remotly.

any ideas sugestions?

Thanks

[gmatthews]

Check out http://jakarta.apache.org/commons/httpclient.

Also maybe check out Burlap + Hessian (in Spring) also as they may offer some advantanges depending on what you're trying to do.

[infectedrhythms]

The servlet has to decide where to send the message first!

So i guess just a quick parse of the message to determine where it should go....

Also the servlet must be able to determine dynamicly where the message should go. Maybe a Db look up or file look up of the available dispatch locations?

Thing is it has to be real fast@

[infectedrhythms]

So if I understand this...

I would be able to deploy my "broker components" as a servlets on jetty or any servlet container...

I need to be as fast as possible so I take it hessian is a better choice then burlap?

As for the dispatcher servlet, it was written pre web services and must stay the same as all my clients use that interface to connect...

How would I decide where to dispatch the request? I would have to keep some sort of list of the available locations and depending on the request send it to the right servlet through rpc. Something simple but robust! Hibernate with caching?

[Ben Alex]

As for the dispatcher servlet, it was written pre web services and must stay the same as all my clients use that interface to connect..

Could you elaborate on what is actually being expected by the clients. For example, they send a request to http://localhost:/dispatch/getTemperature?location=1234, and they get back some XML, with that XML coming from a separate weather service you access via SOAP. The earlier discussion about web services protocols makes me unclear to what extent you're able to change the client interface (if you can switch out to a different protocol, it seems pretty flexible to me). Also, do you have so many possible dispatcher destinations (or they change so frequently) you really need database persistence? Initially it would be less difficult to use a Spring application context to define the dispatcher beans.

[infectedrhythms]

Could you elaborate on what is actually being expected by the clients. For example, they send a request to http://localhost:/dispatch/getTemperature?location=1234, and they get back some XML, with that XML coming from a separate weather service you access via SOAP.

Ok here is the deal...
Pre the whole web services buzz... we created an ISAPI DLL which accepted our own XML message format....
Currently the ISAPI DLL accepts the XML message. When the the request is received, the DLL does a regular string search through the XML and detrmines what database to route to. That being said, the databases are used as tunels to the "broker components" throught extended store proedures.

Problems...
1- The ISAPI DLL is not configurable, so the locations of what dbs to route to are hardcoded within the ISAPI DLL. ISAPI DLLs are stateless (Tougher to track state).
2- Routing through the DB is kinda cumbersom and very egoistic: "I can do my own rpc architecture type of complex thing!" :P
3- Broker components are very heavy weight C/C++ applications, that require monitoring, managing etc...

Solution...
Looking at alternatives...
The interface for the clients must remain the same old XML message format we created.
Now if we program this "smartly"...


The earlier discussion about web services protocols makes me unclear to what extent you're able to change the client interface (if you can switch out to a different protocol, it seems pretty flexible to me)

1- A servlet can be written to accept this old format and disptach the request to a "message parser" or what not...
2- New interfaces such as web services, or xml rpc etc... may be added and they to can dispatch to that same "message parser"...
3- The heavy weight C/C++ apps can be converted to remotable components, that can be instatiated on demand.

This "message parser" or what the appropriate name is... Please correct me :) bassed on the XML will route to the proper "broker component"...

This is where hessian, burlap, corba etc... comme in.


Also, do you have so many possible dispatcher destinations (or they change so frequently) you really need database persistence? Initially it would be less difficult to use a Spring application context to define the dispatcher beans.

So far we are linking to about a dozen or so 3rd parties. So there is that amount of "broker applications" running for us. But would like to simplify their deployment and managebility and we are constatly adding new ones... So it has to be simple and easy to tell the dispatcher where to go.

Thanks