Legacy integration using EJBs


EJB design: Legacy integration using EJBs

  1. Legacy integration using EJBs (6 messages)

    hello there,

    I am trying to find out ways in which legacy applications ( Mainframe apps running COBOL and IDMS ) can be linked to the Web. Solutions using IBM Websphere are not very optimal. Does anyone out there know of or have solutions for this problem? For those who do not know about IDMS, it is a legacy network database which is used by large mainframe shops. I have read that EJBs can be used to encapsulate legacy apps, but have not seen any patterns or code samples for the same.

    - U

    Threaded Messages (6)

  2. Legacy integration using EJBs[ Go to top ]

    The solution that I am suggesting is not using EJB and moreover I have not tried this solution yet.

    But my suggsetion is as follows. Just think about it.

    Use the power of XML to link all systems. if you have a program in Mainframe which can generate XML as output then that it will solve all the probs. The XML is nothing but a plain text, which can be read and manipulated in all available platforms.
    So in java using SAX API, extract the info in it and do all the work.

    So by making the communication using XML, this problem can be solved.
    If you had come accross a better solution, please let me know.

  3. Legacy integration using EJBs[ Go to top ]


    Pls. check the following solutions @.,


    Most of the solutions now use the power of XML to do the legacy integration job.

  4. Legacy integration using EJBs[ Go to top ]


    using XML for the data definition is fine but the problems are actually at a lower level than that. EJB works at an object granularity level whereas host programs (by this I mean their input spec) do not. Therefore you need to deal with issues such as partial instantiation - it's unlikely your existing host programs return the data to populate every attribute in your entity - and the fact that the persistence call used to retrieve data is likely to be completely different to the one used to store data. Remember that even with BMP, the EJB server will be dealing with entities individually.

    One potential solution is to parse your XML data into individual object XML streams and store them in a memory database. Your entity beans can use BMP to store and retrieve state from this memory store rather than the host and you can use a session bean to actually call a host transaction to do the update. However, you must be aware that transactional control is down to you in this case and that is a difficult problem to overcome.
    A better solution might be to forget about entity beans and only using session beans to hold state (so rather than have a Customer entity bean, have a Customer session bean)or have a session bean that represents the whole set of data returned from the host (nasty!). That way, the EJB server will not interfere with your persistency mechanism by calling ejbLoad and ejbStore at inappropriate times. You can also leave your host programs to deal with transaction issues (as they do right now) and your middle tier beans can deal with state optimistically.

    However you decide to proceed, you need to think through the implications of your persistency framework carefully so that you minimise the amount of calls being made to the host, but keep your data transactionally secure.


    Andrew Johnson
  5. Legacy integration using EJBs[ Go to top ]

    Thanks everyone for your helpful comments.

    Andrew: I agree with you that persistence could be a major issue when dealing with legacy apps. Infact that is one of the reasons why we are struggling to come up with a robust solution for the integration.

    Most of the solutions that we have examined use some of form of transactional queues because the mainframe needs to go down for the maintenance, whereas the Web apps are always up and running. Introducing a Queueing mechanism always leads to problems because of non deterministic processing times.

    It looks to me that it will be difficult to use CMP here and we would have to rely on a thin middleware layer which acts as the conduit to trigger transactions on the mainframe : which could be a CICS subsystem. In any case the solutions available right now are not really elegant or optimized for performance.


    - U
  6. Legacy integration using EJBs[ Go to top ]

    Your best bet at this point in time is via IBM's corba interface to CICS or thru MQ. Each of these solutions enable your client java programs (servlets, jsp, ejb) to communicate to cics. The corba interface allows you to write java code that will run in cics regions using jcics classes which enable vsam access, linking to cobol, etc. The requirements are transaction server (I think its version 1.3) and a new version of mvs (I don't remember the version). This is all done via a high performance java compiler which compiles the java source to a load module that you put in your cics region jcl. MQ is another solution for cross platform communication. CICS will be hosting ejb's in the not too distant future, so you might want to check that out too.

  7. Legacy integration using EJBs[ Go to top ]

    heres another two cents....
    if you are working on short timeframes and would want to leverage code residing on mainframe, there are ways where you can convert voluminous cobol code to stored procedures. all you need to do is place jdbc requests from your bean to these stored procedures.