HELP !!!!!! Design decision...!!!!!
Hello,
I am in a dilemma of making a design decision . We are developing a business tier component. This is going to talk to webservices on the backend. Right now it is going to integrate with 2 different backend systems through web services. In future it might support more of such backend systems.
And there are clients (web app, xml app) who interface with the component.
Most of the data elements passed over to backend systems is similar for both the systems, but some are different.
Now is it a good design to make 2 different client interfaces for 2 backend systems ? so that ,clients upfront decide which interface to use. This is more cleaner and easier implementation.
Or is it good to have a generic interface, and component then figures out which data to use and to which backend system to talk to.
Please help,
Thanks
[883 byte] By [
sshanjia] at [2007-10-2 23:25:06]
I would say the second option would be best, purely from an OO perspective. In a setup like this, the idea should be for the front end not to know how things are setup behind the middle tier. The middle tier should know both sides *front end and back end) and the back end shouldn't need to know anything about the front end.
That's the whole idea of having such a middle tier in the first place. If you have a middle tier but all your front and and back end applications still need to know about each other, then why use a middle tier to begin with?
Mark
There are several patterns that could apply, but the most widly used is probably the MVC (Model View Controller) pattern.
With the pattern the View layer is the front end (in your case this would be the web app / xml app).
The Controller would be your middle tier, this layer is responsible for relaying requests of the View layer to the Model layer.
The Model layer would be your backend webservices.
As said, the controler is responsible for relaying the requests from the view layer to the correct webservice. This means you need to have some way to know how to do this. You can employ several methods to do this.
You could have different methods for the different webservices, this is the most straight forward way.
Or you could look at the provided parameters and decide where you need to go based on that. This is slightly more difficult, but when you have two or more webservices that do almost the same thing, this might be the better way to go.
If you really wanted to make things fancy, you could employt the second method and have the checks be based on rules you configure through a dynamically loaded file, this way, you could (theoratically) build your middle tier in such a way that you can add new front ends / back ends without having to redo the middle tier. This might eventually be the cleanest / best way to go, but it is also the most difficult and takes a lot of planning beforehand.
Mark
Thanks again.. that was a very helpful tip.
Now, as I told in my first email, both backend services need different set of data (not completely, some are same) as part of their request from the clients.
Now I was thinking of creating a big fat request object(which holds fields for dataobjects required by both backend services), where clients can fill in available data without knowing what backend service they are going to call and middletier component decides on which service to call based on passed parameter and builds request objects from this client provided request object.
Whenever a new backend service is added to the system, we just add more fields to this client request object .
Let me know your views on this approach
Thanks for you help,
Message was edited by:
sshanji
And I take it you are going to send this big object from client to middle tier via an ObjectStream?
Using an Object for this can be done, no t really all that hard. The only thing to remember is that the object description (class-file) on both server and client MUST be exactly the same. So the moment you add a new client which need one more field in there, you need to redeploy ALL clients since you changed the object.
A more flexible approach would be to setup a XML-interface, where you just put all your variables in a XML-document and send that to the server. This way, you can add more variables later as you develop new webservices without having to redeploy all your clients. Because the old clients don't use the new webservices and thus don't require the new variables to be in the XML document.
Mark
