Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Modularising IDACall for different components

    Hi Team,

    We are currently using:-
    BuildDate Wed Mar 05 15:52:00 IST 2014
    Version 4.1p
    SCVersionNumber v9.1p_2014-03-05

    We have 3 components in our application- Charts,Grids,Maps
    For all these three , the Data Base fetch call goes to IDACall.
    Our requirement is that we want to modularise it such that there are three different IDACAll for three different components as- data fetch call for grid goes to Grid/IDACall/ or chart data fetch call goes to Chart/IDACall/ and map data fetch call goes to /Map/IDACall/.

    And in our configurations we will have these three URLs mapping to different servlets like GridIDACallServlet which extends IDACall.

    Can you please suggest a way to do so.
    Last edited by mchoudhary; 2 Jan 2015, 02:38.

    #2
    This is something you definitely don't want to do. It will just break the ability to use Queuing (see QuickStart Guide) while not providing any modularity at all.

    In fact, placing component-specific logic in servlet classes is also a bad idea - if you need component-specific server logic, it should be done using dsRequest.operationId / component.fetchOperation to route calls for a specific component or set of components to a particular operationBinding.

    We should also mention: the fact that using separate servlets seemed like a good approach strongly suggests that you are in need of Architecture Review.

    Comment


      #3
      Thanks for quick reply!! Really appreciate.

      When you say having component specific servlet is not a good idea does that mean all the IDA calls we have should be directed to single IDACall servlet & by checking operation id make a decision which service class should handle it. Infact this is what we are currently doing.

      The challenge we are facing here is that we have 100's of operation-ids across 4 components (i.e. Charts, maps, Grids & filters) and as off now all calls are handled by single servlet.

      With each request received by this servet we do if-else check among these 100 of operation Id which class should serve that request. This comparison logic is pretty cumbersome, thats where we believe having URL based servlet mapping will do first level of separation.

      Let me put again what my thought is, kindly validate again:
      --------------------------------------------------------
      We are planning to create 4 IDACall servlets (i.e. one for each UI component like GridIDACall, MapIDACall etc). Plan is to configure there 4 servlets with different servlet-mapping in web.xml to ensure that dsRequests related to one component is handled by a specific IDACall servlet. Saying this mean.. all types of dsRequests for grids will be handled by GridIDACall servlets & likewise for different map types...

      I believe with this approach we can still leverage queuing of requests as all dsRequest to one type of component is still handled by one servlet.

      Please suggest!!
      Last edited by mchoudhary; 3 Jan 2015, 05:04.

      Comment


        #4
        Not sure how to respond except to reiterate what we just said...

        You absolutely do not want multiple servlets. If you have multiple Servlets with different URLs, you can't use queuing with requests that are going to different URLs.

        There is no reason you should have built a giant if..else statement in a Servlet. The SmartGWT server architecture provides the ability to have different DataSources with different .ds.xml files that route dsRequests to different logic based on the DataSource ID and operationId.

        If you've been completely ignoring this system, it's time to start using it instead of continuing with your primitive if..else dispatch. Splitting your if..else dispatching logic into multiple servlets is just going further in the wrong direction.

        And once again, with this level of confusion, you would greatly benefit from our Architecture Review service. Everything you've said here strongly suggests you've been taking the wrong approach pervasively, which is probably leading you to do a lot of unnecessary work.

        Comment

        Working...
        X