EAR plugs ...


EJB design: EAR plugs ...

  1. EAR plugs ... (9 messages)

    Can anyone help my with the following design challenge (i have some ideas myself, but like to throw this in the group).
    - i have several customers (say a few hundred) which i identify via an ID (which i wil call my custID).
    - every customer has its own website (same underlying mechanism, but different themes and style). The websites are managed by (my) servlets, no problem here.
    - each customer uses an URL like "https://www.formcentral.com/customer1" ('customer1' is my custID). So, also "https://www.formcentral.com/customer2", "https://www.formcentral.com/customer3" ... and so on.
    - the main servlet interacts with my application, which is an J2EE application running on a JBoss application server.
    - Several SLSB are called (via JNDI, you know, the standard stuff) from the servlet(s). The custID is past along with every conversation (method-call) between servlet and a SLSB.
    - there's only 1 EAR deployed.
    - each customer has its own mySQL database. And there's a connection pool for every customer. This is configured via the mbean-services on the JBoss app server.
    - i use BMP entity beans in combination with DAO classes (generated with xDoclet).
    - all the code in the application (SLSB's, BMP, DAO's) are the same for all customers, only the Datasources differ, and they are looked up via JNDI in the DAO classes. So i have a configuration file somewhere which contains the custID's and their corresponding Datasource, e.g. "jdbc/mySQLcustomer1".
    - conclusion: 1 EAR manages all the traffic from the different websites to the correct databases.
    - PROBLEM/NEEDS: 1 EAR is a great advantage, but also a great disadvantage. When you have 200 customers and you want to give 1 of then a brand new version ... that's a problem, because i don't want to influence the other 199. And that is only 1 example.
    A possible solution is to make 1 EAR per customer (customer1.ear, customer2.ear, ...). So i will have 199 copies of the same code, of the same ear ... and 1 ear for my brand new version. I could use the customer name in the JNDI-naming to distinguish the customers. But the disadvantage here is that i'll have massive loads of (the same) code running on my JBoss.
      Can you see my problem ? And can someone give me some hints ? Has anyone been in the same situation ?
    If something is not so clear, i can clarify if you wish ...

    Thanks in advance of any help.

    Threaded Messages (9)

  2. EAR plugs ...[ Go to top ]

    Wil -
    Not sure I understand why you have a db per customer, that seems to be an administrative nightmare. (Since each customer has a unique id you could use it to partition their data in one schema.) Anyway, there is an interesting article in this month's JDJ about hot deploying without going down. Their model leverages JMS to do it. Another hybrid approach would be to implement JMS and utilize it's self healing capabilities within namespaces to ensure uptime and allow you the ability to dynamically redeploy. Either way, it is a complex issue for sure.

    Hope this helps -
  3. EAR plugs ...[ Go to top ]

    Sorry, lack of coffee, the last section should be Jini not JMS... :)

    Another hybrid approach would be to implement Jini and utilize it's self healing capabilities within namespaces to ensure uptime and allow you the ability to dynamically redeploy.

  4. EAR plugs ...[ Go to top ]

    I would suggest you treat your EAR as an application with versioning. When you create a new release of your site-management EAR number, give it a major version and deploy it on the server. Leave the old version installed. Give customers the option to upgrade to the new version by tweaking their URLs (with a redirect from the older URL).

    Therefore, you end up with 1 EAR per major version: 1.0, 2.0, 3.0 etc.

    When you make bug-fixes, you can update minor version numbers: 1.0.5, 2.0.2, 3.0.1 etc.

    Anytime a client asks for a specific new feature, see how you can integrate it with your general development path. If new features are optional, manage this through configuration (in customer-specific XML configs or config settings in the database).
  5. EAR plugs ...[ Go to top ]

    Hi Wil,
    Could you please elaborate on what features you are planning to differ for each customer? Would like to ponder on this issue as it is a very valid one.

  6. EAR plugs ... extra[ Go to top ]

    Hi everyone,
    (sorry for my late answer, but i'm i a different timezone :-) )
    I will elaborate on this subject later one.
    - For Jon: you're right; 'customer' is a little vage. 'Site' would be a better word, I actually call them area's. Our customers are cities and towns, so we make a website and a separate database for them. The 'users' of the system are civilians and public servant (you also have system administrator, and so on).
    So there's an EAR per area (town/city).
    - For Saju: only the website differs area for the moment; put that is not an issue here (these things are handled by XML,stylesheets & css and by specific setting in de DB for that area (so, only the content differs, not the structure of the database)).
    - For Paul: what do you mean by 'tweaking their URLs' ? A servlet (or some helper action class) perform a JNDI-lookup to my SLSB (facade), 'area' is not used for this lookup. This procedure is actually the same for all area's, but the area is passed to the SB via an extra parameter (or embedded in passed object actually). The area is then used to lookup (JNDI) a Datasource for the correct database. I want to get rid off 'embedded' area, and use it in a more declarative matter, and i guess that i could extend the JNDIName;
    -- servlet: lookup JNDIName 'ejb/Brussels/WorkFlowFacade'.
    -- DAO: parses the area 'Brussels' in the JNDIName above.
    -- use the 'area' to get the correct Datasource.

    More, later on. Have to go now.
  7. EAR plugs ... extra[ Go to top ]

    Correction, sorry - also a coffee problem, i guess :-) -

    So there's an EAR per area (town/city). should beI have 1 single EAR to handle all area's (towns/cities).
  8. EAR plugs ... extra[ Go to top ]

    For Paul: what do you mean by 'tweaking their URLs'?

    Answer: If you are going to host several different EAR on the same server, each with different web applications, you will need some way to distinguish them. The only way to do this is with a different context-path for each web application.

    When I said "tweaking their URLs", what I meant was that you could update each site's to redirect [response.sendRedirect()] to the correct home page for each different EAR from the home page of your "main" EAR. You could manage this in some kind of configuration file, or from data in the database for each client. That way, each client can choose to use the version of your application that they need.

    This will be especially useful if you are working for concervative organizations like governments, because it will be unlikely that they will all want to upgrade at the same time. This way, you can leave older versions of your application in place but allow some of your clients to upgrade to new versions.
  9. EAR plugs ...[ Go to top ]

    Jon, can you give me the URL for that article ("... interesting article in this month's JDJ ...") please.
    Thanks -wil-
  10. EAR plugs ...[ Go to top ]

    Wil -
    Sorry for the late reply, been busy. Here's the link to a synonpsis of the article. Non-Stop EJB Services

    Unfortunately they want you to be a member to read it online, however you can get a copy at your favorite book store. Again, I'd suggest investigating Jini. What you could do is have you're primary app server(s) manage authentication etc., basically a proxy Jini client that leverages Jini's namespaces to point your users to the correct services. Anyway, it's just a thought. Regardless, good luck! :)