How flexible is the JAVA Connector Architecture?

Discussions

General J2EE: How flexible is the JAVA Connector Architecture?

  1. Lets say I have a fanacial application, that need to connect to a 3rd party bank...

    Bank requirments...

    - TCP/IP protocol
    - 1 persitant connection
    - Bank sends ping "message" to client (my application) and application must respond back.

    Is it possible to implement this?
  2. Hi!

    First of all, a JCA adapter must run in a J2EE container to work. This means the "application" must be an EJB or a Servlet/JSP (with the possiblity to build anything on top of that).

    The "one persistent connection" requirement is not in good agreemnet with the ideas of JCA. The application server should manager the connections. (Works like JDBC when it comes to connection pooling etc.) On the other hand, it is possible to implement JCA using only one conneciton.

    I do not expect connectors to be used outside firewalls. (Who should use a JDBC driver through a firewall?)

    JCA cannot be used for communication from server to client. I have seen some ideas about adding such functionality in the future, but that is not event on draft level today.

    I expect connectors to be delivered with most systems in the future (like alla database vendors deliver a JDBC driver), and normally I don?t think programmers outside the valls of such vendors will write connectors. (For the same reason as you seldom plan to write a JDBC driver...)

    So, to answer the question: My reply must be "no" based on the "ping" requirement.

    /Tomas
  3. Ok so I misunderstood the whole point of JCA...

    What I have is the following... Not done in J2EE but just using standard, C++ and ASP (Active Server Pages) etc.. a Microsoft solution... So I want to take a look into moving over to J2EE

    So my curent application is designed in this maner...

    An ISAPI DLL accepts an XML document. The XML document is placed in the database. Now bare with me alot of the application logic was done though stored procedures within the database. Scalability = 0, robustness = 0, transaction management = created manually through states and flags and sux! Anyways...

    So the XML document is placed in the DB then subsequent stored procedures are called and the XML data is processed etc...

    Meanwhile the ISAPI DLL is poling the DB for a status on the inserted document. Once the flag is set the ISAPI DLL picks up the result and sends it back to the client...

    On the other side of the DB there is also a few applications that are connected to 3rd parties. The apps are polling the DB to see if any docuements where inserted. When a document is inserted the applications take the document, format the document to the 3rd party's format spec and then send it to the 3rd party...

    3rd party does what ever and returns a response back to the application, application puts result back in the DB some more processing is done and finally, like mentioned above the ISAPI DLL returns the result to the client...

    So now all sides, ISAPI, DB and applications are checking states etc... Transactional hell :P

    So I started looking at j2EE and started figuring out the following...

    The ISAPI DLL can easily be replaced with a servlet or a web service. Most of the logic can be removed and be placed in EJBs. Now I saw JCA and I said to my self this would be awsome to replace the applications in the back. But I guess not... Because the applications require x25 lines, special ISO standard message formats, persistant TCP/IP connections, FTP, HTTP etc...

    One way I figured is... Maybe to use JMS synchronouly, since the data is processed in real time and a response is returned emediatly... So bassically the back end apps can tie into the JMS of the app server and listen for messages. Or maybe a message driven bean can be notified and then possibly format the message to the 3rd party's spec and then forward the message to the application which in turn will go to the 3rd party. And I can probably make the applications transaction aware and have them tied in with the rest of the transaction within the app server.

    There is also the case where some requests dont get processed right away but once a day... There I would be able to use JMS asynchronously and send the messages at the end of the day to the 3rd parties.