Design IDEA

Discussions

EJB design: Design IDEA

  1. Design IDEA (7 messages)

    Hi All,
    I need your help redesigning a CreditCard Proccessing Application.
    Currently, The CCApp consists of two client-server applications. the first server act as a trafic controller, it delivers sockets to the calling clients then pass the client request to the second server that implements a queuing algorithm to allow four different modems to connect to the actual credit card processor to authorize credit cards.

    issues:
    The credit card processor can only except modem connections.

    the trafic controller is written in old java while the queuing server is written in VB.

    I want to redesign this whole thing in a J2EE environment. JBOSS and MDB? IDEAS?

    Thank you in advance

    Threaded Messages (7)

  2. Design IDEA[ Go to top ]

    Maybe you should adopt a process of elimination, and perhaps you can first strike out EJB's? I'd certainly be wary of having the second server as an EJB application server (it is against the spec for EJB's to manage socket connections and I would be inclined to treat modem connections in the same light). However you could have a modem controller outside of the container that acted as an client for EJB's if they were necessary.

    Apart from that, I'd recommend studying the old code/documentation and identify as many design and architectural patterns as you can, as well as deficiencies. A decent J2EE architecture could be based on that.
  3. Design IDEA[ Go to top ]

    Ian,
    Thanks for you quick reply.
    Well, EJB is not my favorit neither is socket programming. However, I thought I could use MDBeans to do the task of receiving requests from the client (ex:servlet), parsing the received data, queuing, sending request to one of the available modems, receiving the results back from the modem, and finally returning the result back to the client(ex: servlet).

    I forgot to state that each transaction takes between 25 to 30 seconds because of the modem.
    What do you think?
    Ahmed
  4. Design IDEA[ Go to top ]

    Ahmed,

    in my opinion, the MDBs and JMS are probably useless in your situation. I recommend using Stateful Session Beans for the modem connection server (2nd server), and plain Java multithreading client for the socket connection server (1st server). Since you have four modems, the limit for the 2nd server SFSB pool will be 4 max.

    What's your requirement regarding the tcp transaction timeout? i.e. when all four modems are busy, but the tcp connection keep coming in? Is it ok to wait indefinitely until one modem will become available?
  5. Design IDEA[ Go to top ]

    Hi All,

    > I need your help redesigning a CreditCard Proccessing Application.
    > Currently, The CCApp consists of two client-server applications. the first server act as a trafic controller, it delivers sockets to the calling clients then pass the client request to the second server that implements a queuing algorithm to allow four different modems to connect to the actual credit card processor to authorize credit cards.
    >
    > issues:
    > The credit card processor can only except modem connections.
    >
    > the trafic controller is written in old java while the queuing server is written in VB.
    >
    > I want to redesign this whole thing in a J2EE environment. JBOSS and MDB? IDEAS?
    >
    > Thank you in advance

    Unless I misunderstand your requirements, you wish to place a (transactional?) middle layer between clients and the CC processing backend, correct? (Thus EJBs?)
                           ****************************
                           * *
                           * I-2 I-1
                           * Req | |
    [Client] --> [Router] -*-> [Queue] -|-> [MDBean] -|-> [Modem] <---> ...
                           * | | |
                           * JMS | Connector
                           * Res | *
    [Client] <-- [Router]<-*-- [Queue] <------ *
                           * | *
                           * Err | *
    [Client] <-- [Router]<-*-- [Queue] <------ *
                           * *
                           ****************************
    I-1:
    Per J2EE architecture, you would need to write a Connector for the Modems -- you would treat the whole thing as an EIS -- analogous to a DB. That would take care of presenting your EJBs (of whatever kind) an interface to the modems. (Unless you wish to reuse the modem connectivity part for other (totally different) projects you may simply treat the whole thing as a 'CCProcessor' and create a simple interface for the CCProcessor Connection, such as ProcessCCTransaction (..), etc.)

    Since your modem number is fixed (e.g. 4 modems), in your Connector design you may wish to either treat each modem as a specific (i.e. 'named/indexed') EIS, OR handle the multiplexing of requests to an available modem in the Connector driver itself. (i.e. as far as EJBs are concerned, there is just this 'system' that accepts CCProcessing transaction requests and processes them -- they have no idea that modems are involved, much less how many modems are involved.)

    So once you have I-1, you have a hook (which can become transactional, BTW) from EJBs to your modems and back.

    OK.

    Now, I-2

    The requests for CCProcessing are pushed to an MDBean listening to a CCTxProcRequests queue. The MDBean gets a requests, and uses the Connection to the CCProcesing EIS (which is most likely cached in its context) to process the request .. waits 15-30 secs .. and then either sends a TxReceipt or TxFailure message to a CCTxProcResults or CCTxProcFailure Q (respectively).

    This means you probably need to generate a Tx ID at a forward layer and associate that meta-info with the actual CCProcRequest, and use that Tx ID when generating the result messages.

    At this point you would have an asynch CCRequest processor running on J2EE using MDBeans and Connectors. The connector sub-system would likely require writing Java wrappers for your COM objects which actually do the interfacing with the modem hardware -- unless you wish to port that code and have a pure java solution.

    (This is denoted by the '*' boundary above.)

    What is not clear is the servlet/socket bit. Perhaps you wish to elaborate on this, as it really doesn't seem like a natural fit for J2EE.

    (Note that you can certainly treat your router as an EIS as well, and wrap the sockets with a Connection. That would have been my recommendation if it was the EJB(s) which needed to _initiate_ a socket based comm link, but in this case it would be the EIS (e.g. the net interface layer -- aka 'router') that initiates the link and I don't think that would fit nicely into Connector spec.)

    Hope this helps.

    Peace.
  6. cut and paste it using a fixed font and see the clear picture ;)
  7. Lets see if this works[ Go to top ]

    <code>
                           ****************************
                           * *
                           * I-2 I-1
                           * Req | |
    [Client] --> [Router] -*-> [Queue] -|-> [MDBean] -|-> [Modem] <---> ...
                           * | |
                           * JMS Connector
                           * Res | *
    [Client] <-- [Router]<-*-- [Queue] <- *
                           * | *
                           * Err | *
    [Client] <-- [Router]<-*-- [Queue] <- *
                           * *
                           ****************************

    </code>
  8. Lets see if this works[ Go to top ]

    Joubin,

    Thanks for your help.