Discussions

EJB design: Presentation-only clients and how they request their data...

  1. Hi there !

    Although our problem is not directly related to EJB, it should probably share the same design guidelines.

    We are trying to build our application according to the following 3-tier architecture:
    - Lightweight clients written in Java, taking care of the presentation stuff only
    - Corba servers hosting the actual business logic
    - The persistency is achieved by standard SQL databases

    Let's say that our business deals only with these three types of business concepts/objects:
       CUSTOMERS linked to their billing ADDRESSES and INVOICES

    At one step, the client application must be able to present to the user a list of customers living in a particular city and having the total amount of their invoices greater than a given value. The output shown on the screen contains the customer's name & address together with the total amount of their invoices (thus including attributes/properties of the three business concepts).

    The task of finding the required information is, of course, delegated to the second tier (our Corba servers).

    Now the QUESTION is:
    --> how do you send back such result to the presentation tier (our client application) ?

    Here is what we currently have in mind:
    The result would be sent back to the client as a very specific 'value object', tailored to this particular query method.
    Of course, this completly breaks the object model on the client-side. This value object is more a collection of data structured in such a way we can decode it. The client will not share the same model as the business servers.
    Is this normal ? As we have a presentation-only client, we thought it is acceptable: the only requirement is to be able to display the information to the user. Who cares if we are working with kind of flat data structure instead of a nice object model?

    The implementation of the requested service is done in a 'facade' built in front of servers holding the shared business logic & entities. This facade is tailored to our application and provide very specific services according to both our application and presentation requirements. We would possibly have as many facades as we have different applications sharing the same business logic & entities.

    This comes from the fact that the way you define your application flow has an impact on how you will access your data, right ?
    I mean, if we wouldn't have said that we want to display the output as described above, our requirements would be different: the data needed for the presentation wouldn't be the same and the services requested by the presentation client would be different either.


    To be honest, I don't feel comfortable at all with these idea. All this looks very strange to me but don't know exactly where the big mistake is.
    I would be very happy if someone could react on this, even by saying I'm stupid and don't understand anything (provided you tell me what I don't understand ;-)
    Thx

    -Bertrand
  2. From reading ypour description I dont have an exact picture of what the exact nature of the problem. But my gut feeling tells me you are struggling with how to implement a MVC (Model-View-Controller) design pattern. Let me refer you to JSP Model2 as published by sun, this pretty much applies in Swing/JFC clients aswell (you didnt mention whther you have Browser or Application clients), but anyhow it shouldnt make a difference.

    The key abstraction here is that your CORBA servers should service out Data Views for Presentations that are pretty much calculated on the server side, the you use these views to set them as the Model for your UI on the client side.

    I'm happy to help you further if you can tell me a bit more about your architecture, and then I can go into more detail about the above proposed approach.

    let me know.

    Emad J. Benjamin.
  3. Ouah, fast answer ;-)
    Thx a lot...

    Clients are Swing/JFC clients, not browsers.
    I understand the MVC pattern you tell me, but it is quite good you point me on it.

    As you say the CORBA servers should service DataViews suitable for the presentation. These views have nothing to do with the business objects the server may have to deal with, right? The represents the result of a particular service. In the example I took, the DataView would contain the customer name, the address and the total amount of invoices. All in 'one row' (flat structure). There is no Customer object in this view as we would have on the Corba server.

    (Let's say this DataView looks like the result of an SQL join I would have done in a traditional two-tier application.)

    In the client application, I use this DataView as input for my presentation models. Fine.

    BUT, each Corba service/method may possibly export a different DataView. Example:
    a/ In application screen A, I have to show a list of name and VAT number of customers matching a criteria.
    b/ In another screen B, I wanna show customers with their names, contact, status or whatever.

    Although these two screens display customer information to the user, they are intrested in different subsets (views) of the customer properties. I would then have two different DataViews returned by two different Corba methods.

    As consequence, the presentation client wouldn't have any Customer notion/object (which is fine for me as long as the client application deals only with *presentation* logic and delegate all the actual business to the Corba server).
    Agreed on this point?

    Another point is that these DataViews are not likely to be reusable by other client-application. Why? Because they are bounded to the presentation stuff, and two applications will have different presentation requirements, although the may share the same business.
    Even the JSP and Swing versions of the same application will not share the same presentation requirements (maybe).

    So now, how would you sketch these DataViews ?
    As kind of PropertyContainers (list of properties) or actual Objects with well defined interfaces (getCustName(), etc)?

    Another point is that I don't think you can directly use them as 'model' for the application: there is no way to update these DataViews (and in most cases it doesn't make sense).
    Example: my DataView contains customer names and VAT numbers. I want to be able to update, through the presentation client, the customer VAT number. To commit my changes back to CORBA, I have to call a method like updateVAT(custId, VAT)... or event worst, request the full version of the customer (as a copy), apply the changes and submit it to the server for validation (let's say I don't like this way of working since the server don't exactly know what has been done - it can just check the validity).

    I stop here, waiting for your feedback.

    PS: where can I found the JSP Model2 document you mentionned - or any other doc that would be helpfull ?
  4. Its getting to the point where a whiteboard would help. But let me answer one of your concerns, and then later I can comeback and buld a suitbale architecure for you.

    When get the DataViews back, you are right you can set them, as Models, but what you can do is right some factory whioch produces the models you want, the model producing methods could very well be part of the DataView obvjects. DatavIewObject.getModelForAcertainPartOftheScreen(), etc. This is very Swing specific, and it sounds the Model (NOt View calcualtion) is Swing speciifc and is code that will not be reused in the JSP client/Browser, but you will definitely be able to reuse the DataViewObject/Calcualtions to serve up JSp pages with Data, but lkets focus on the Swing application.

    So far you should havd:
    A Data Access Server (Corba server which return) data Beans,
    The you have some sort of DataView manager, or whatever for each significant part of the business, this Manager/factory would return DataView Object pertainign to screens, then from these objkects you can get the model, so far everything is on the server, once you get the model, then you can set on the client JFC component on the client side. What do you think, make sense here?

    More later...
  5. Emad,

    Yep, guess a whiteboard is what we need!
    We could arrange an only NetMeeting together if you want ;-) (if interested, send me a mail: 'bertrand at itma.lu' - decode the addresse yourself - I just don't want search engines to index it). We would then post a summary back on this portal.

    What you say make sense.

    Let me tell you a bit more about our global architecture.

    a/
    We split our business into several domains to reduce the overall complexity. They are managed by distinct DOMAIN servers. These servers implements the domain specific business and integrity rules. For our example, let's say we have the Customer Management, Warehouse and Product Management and Accounting domains. Customer records and their addresses are 'hosted' on the Customer Domain Server, while invoices are treated by the accounting, etc.
    This example is very simple but it illustrates our architecture.

    b/
    The actual company business runs on top of these domains and define rules, policies and procedures on top of them. Let's say we are at the level of global use cases that define how people do their job. For example: one will define how to process and order coming from a customer. This will involve all three domains listed above.
    This logic is implemented into a set of APPLICATION servers that make use of the DOMAIN servers to delegate part of their job. Inter-domain transactions are handled at that level, so are these global or application-specific rules.
    These application server make use and understand the same object model as the domain servers. I mean, they are working with the same business concepts. They just provide specialised services that are not directly provided by the domain servers.
    In one sense, the host the application logic - the logic specific to a given application and not shared by the others.

    c/
    Then comes the client-side. As I said, we want lightweight Swing clients (thin/Web clients are foreseen in the future).
    As the application logic is already hosted somewhere else, these clients will only deal with the presentation part.

    c.1/
    We first thought we could directly build these clients against the services exported by the application server.
    Problem is that these application servers were not designed with the presentation requirement of the client in mind. They focus on the application logic - what processes must be carried on to achieve the business tasks.
    Whatever kind of client you have (Swing/Http) or whatever screens you may have, the application logic should remain unaffacted. Right ?

    The result was that services exported by the application servers were not always suitable or efficient. Example: 'retrieve and display all customers living in a big city having at least two invoices'. This wasn't actually foreseen at the first time.
    QUESTION: is it part of the application logic or is it a presentation requirement ?

    Anyway, we had first to implement this on the client itself... that resulted in very poor performance and lots of calls to the server.

    Then we thought we had probably to move that functionality closer to the data and avoid doing it over the network. Wise decision isn't it - Take it as a rule of thumb: keep your processing as close to the data as possible ;-)

    c.2/
    Then comes our second decision: move this part onto the application server. At the same time we wanted to avoid transmitting useless data to the clients.
    Example: only retrieve customer name and VAT number and forget the other properties.

    In the first step (c.1) the client application was working with the same model as the one exported by the application server (which came from the domain servers, remember?). This appeared to be inefficient in most cases. Why? Probably because we have a PRESENTATION client that cares only about what it needs to show to the user. Working with a Customer or Invoice object at that level is irrelevant.
    QUESTION: Am I right there ?

    So we thought about a kind of Presentation Facade in front of the application server... This facade whould care about collecting only the required information. A change in the presentation requirements (additional info to be displayed) would imply changes in both the client and the presentation facade. All of this for the sake of network bandwidth and processing efficiency... Moreover, that facade would be dedicated to this client and isn't reusable at all.

    This is actually where your DataView would take place, right ?

    I don't feel that comfortable with this approach and don't exactly know why...
    QUESTION: tell me what you think? Is it a valid approach?

    If yes, then I would be very happy to go further with the design of this DataView interaction and how I can build my presentation layer (client and facade) with this concept.
  6. Hi Bertrand,

    I think you're stuck with a misconception, and the best thing to do is to get over it and do your job without being affraid of conceptual overdose .

     Not everything should be an object, and not necessarily OO concepts are best when applied everywhere.
    Your user will not care at all what lies beneath (EJB, CORBA, SOAP, .NET, or just plain old efficient SQL), it's bringing them correct data in a timely manner.

    You can think that if you don't do it "the right" way, or let's say the "politically correct" way, then you'll get into trouble with things like maintainance, scalability , performance , high availability, and so on.

    Well, there are many way you can shoot yourself in the leg, and I can assure you that the chance to do it if you don't keep it simple is very, very high.

    So, you don't make any big mistake with your design, go ahead and get the results!

    P.S.:
    Think of your database differently :
       - NOT that persistency is achieved by standard SQL database
       - RATHER the state in the database is the tangible and persistent result of the whole system (together with printed reports maybe). You implement business processes on the data by using OO representation of the data, but it's the data that matters.

    Writing business applications is not supposed to be some kind of rocket science (although we may like to leave that impression, so we'd get a nice big pay for it).
  7. Costin,

    Unfortunately, you are right... It is not rocket science ;-)
    I agree on the fact the user doesn't care about how the application does its job provided it does it correctly.

    Problem is I'm not the user, but the programmer... And I'd like to do my job the best I can, according to the rules. Maybe I'm too much focused on the code and design rather than on what the user will get.

    As usual, the truth lies somewhere in between. In the past, I had the chance to meet people who were able to produce very nice design, highly flexible systems, comfortable user interfaces... all this within deadlines. I'd like to reach that point once in my life, it probably requires enough experience. So I keep learning from others and hope I'll succeed.

    You said: "don't make big mistake with your design"... Does someone knows what a big mistake is? Is a mistake still big in two different context? Well, in my case I wonder if they aren't any big mistakes in our design ;-)

    PS: Funny enough, my boss shares your point of view. But he is also the guy who puts requirements like flexibility, robustness, reusability, scalability, methodology, etc all at once... All this requires a good design somewhere, right?
    Anyway, I'll probably have to proceed the way you said, because of time constraints :-(
  8. Bertrand,

    I'm also a programmer, have some years on the "server side front", and I have some qualifications as DBA/Database Designer .

    You don't have to have any misconception about what constitutes a good design. Not necessarily OO, Distributed, J2EE compliant give you premises of a good design and in some instances care should be taken.

    It seems to me that you hit the wall where you discovered that OO, distributed representations of Domain Objects suffer an inherent drawback. You cannot query them.
    There's no way you can have the power and efficiency of SQL against an object model, no matter how well considered and well designed that is.
    Not to mention they are far from scalable, because they have to be full blown memory layouts dictated by a compiler
    and a linker. Of course, you can find tons of patterns that work around some deficiencies but don't address the structural problem.

    If you think client applications should be programmed only against an Object Model (let's say an Object Functional model), then you're stuck with it, there's no way your clients can query data, prepare nice reports, flexible ad-hoc queries that users think they should be granted.
    You can even look at this site, that uses an HMTL indexing engine for searches ... as an example of this limitation.

    What to do about?
    The solution largely depends when your progress so far, on whether you use different databases for the "domain models" you're trying to query and so on.
    Try to get over the "data independence" , "transparent access", and other nice to have features of the current fashionable trends.
    They don't give you neither scalability, nor flexibility, nor efficency.

    You could expose the clients to the data model and offer a gateway in the middleware that would allow client to send full blown SQL or at least some kind of WHERE clauses and get back the needed information.
    Your clients will then depend on the datamodel or at least some knowledge of it.

    So, what?

    There is the myth that the presentation layer can be dependent only on the business logic layer and business logic (object domain) only vaguely on the data layer (eventually by making use of sofisticated O/R mapping tools the later dependency could eventually be transparent to the programmer).

    I can prove this is a bad design for business applications, so if you're interested send me a mail with ccozianu at cis.canon.com.
    Or we can chat about it.

    In the meantime, the only advice I have for you is get the job done and any design that does it will be not as worse as you think it could be, and certainly better than designs that don't do the job.