Atul Apte

Hi,
I am interested in knowing how easy or how difficult is it to develop plugins for Java developers such as testing tools, generation tools, viewers etc.. Does Eclipse have the facility to quickly develop GUI extensions? Supposing I want to develop a modeling plug-in for a specific domain.. can I use Eclipse GUI framework to easily develop a UML based GUI interface?
Regards
Atul

Hi,
I wrote a book on Java Connector Architecture, the emerging standard for integrating enterprise systems with J2EE based business applications.
The Book is available in the market since May 2002 and I have received good feedback over the last 12 months.. As as followup I am planning on a second edition of the book and would welcome suggestions to add/change/improve the book.
Also, if anyone of you is working on software integration projects, checkout my companies website www.iconexio.com as we provide free adapter development tools for Java developers. These tools enable you to follow my book and develop connectors faster/better/cheaper.
I also speak at conferences and will be chairing a committee on adapters for the EAI Industry Consortium www.eaiindustry.org starting August 2003.
Regards
Atul

Fei, Rashmi,
Hope this reply can be applied to both of your questions.

Fei, I totally agree with you that maintenance can be a big issue for web services. Mainly because there is an element of trust and support of the web service provider that needs to be considered. However if you are deploying web services internally that maintenance job should become a little easier.
Nonetheless if you are dealing with J2EE integration (J2EE apps to legacy apps) then JCA is the way to go.
Rashmi, Thanks for taking the time to explain your perspective on the JCA by using an example. I have a couple of things to say about it.
First JCA is not tied to JMS. Yes we can use JMS as a mechanism to send request/response messages to the legacy system but the JCA specifications do not depend on JMS.
However the client of a JCA adapter could well be an EJB that is based on JMS (message driven bean).
Also the concept of event adapter and service adapter is not specific in JCA. Those terms are not defined in JCA 1.0 specs. However your idea of developing event adapters and service adapters is correct and will help solve the integration problem you have defined in the example.
Regards
Atul

Arif,
Are all the systems or applications you are talking about J2EE applications? I guess not. In that case building JCA adapters will be useful if you need to integrate these applications with J2EE applications either now or in future.
Atul

Manish,
I think your architecture and idea of using a servlet over HTTP will work. It will be better to get an idea of how many transactions or messages you expect to process thru this channel.
If that volume is very high then it may be better to go with an async messaging platform as the middleware.
The best strategy is to use a framework that will enable you to plug-and-play components as you scale the number of transactions between Siebel and other systems. The framework should also help simplify the management aspect of the integration components.
Have you documented the integration scenarios? In my book I have also mentioned why integration scenario analysis is important to any integration project.
Atul

Fei,
In my opinion JCA is the way to go when your business case is about a J2EE application requiring to integrate with non-J2EE application.
For other scenarios like legacy systems accessing J2EE applications, JCA is not the ideal choice. Message driven beans or web services (for the J2EE application) will be a better choice.
Building a JCA adapter for a legacy system only helps a J2EE application get access to the legacy system. What if the legacy system already has a web service? I will still build a JCA adapter to maintain a consistent CCI based interface to the EAI tools.
Hope this makes sense.
Atul

Congratulations to the winners. Hope you find my book useful. I look forward to your feedback.
Another channel to stay in touch with my involvement in adapters is to subscribe to our newsletter "Get Conenected". Go to www.iconexio.com and subscribe. The newsletter is free and gives me an opportunity to share thoughts and experiences with you.
Atul
[ May 03, 2002: Message edited by: Atul Apte ]
[ May 03, 2002: Message edited by: Atul Apte ]

Data Synchronization across application databases is an old problem. Some databases have database mirroring capabilities which will work if the database models are identical.
I prefer to look at the design patterns (as described in the Gang of Four Design Patterns book) and specialize a sub set of patterns for data synchronization.
The command pattern, singleton pattern, and visitor pattern are some of the fundamental patterns you can look at if you are developing your own data synchronization solution.
There is a better way, use an application integration framework to manage the data synchronization and future change management will be simpler. Don't just think of solving the current problem, put some effort into future change management too.. as it is bound to happen.
Atul

Hi Sanjay,
That depends in part on how mission critical is the small application to the integration scenario.
The application may be small but if its critical to the scenario then a JCA adapter is still justified in my opinion.
You are right in asking the question in terms of the cost involved in developing JCA adapters and their usefulness.
I personally prefer to use an adapter framework that can be implemented as a JCA adapter when required or an EJB, or a standalone component, depending on the integration scenario.
Also, with more resource adapter vendors the cost of adapters for ERP and other packages should go down.
Atul

Manish,
The scenario as you described is one of the cases which are not ideal for JCA JCA works best when a J2EE application requires information from EIS not the otherway round.
However in my book I have described a very similar scneario and how to potentially solve it.
Your approach seems right although there are too many moving parts in between. Managing the scenario will be difficult at runtime as the volume of transactions go up.
However, here's what I would suggest.. Choose a specific MOM if you haven't already done so. Preferably a JMS compliant MOM like MQSeries. This hopefully will eliminate the need for an adapter on the J2EE platform side.. a message driven bean may be enought (as you have stated).
Also I would look into session management between the adapters (the message driven bean, and the IIS based directory monitor). This will be needed to ensure there is no data loss, and request/responses are coordinated properly.
If you log on to our web site www.iconexio.com and send us an email with a little bit more detail on platforms, MOM, etc. we can send you our integration plaform/tool for evaluation. It may help you solidify your architecture and concepts.
Atul

Ruilin,
JDBC is not the same as JCA. In fact JCA and JDBC are complimentary to each other. JCA resource adapter makes use of JDBC to access databases. A JCA resource adpater is expected to do more then just access database tables. It is also expected to expose a standard CCI interface ensuring consistent API to access database and other legacy applications.
The JDBC API is very different from the JCA CCI API. You will see the JCA CCI API support XML and other EAI tools whereas JDBC won't.
In my personal opinion, moving forward SUN will have to define the boundaries between JDBC and JCA as well as the use cases more clearly.
I see JDBC as a driver that enables JCA resource adapters to get access to RDBMS at a database level. There will be similar drivers (JMS, etc.) what will enable a more richers set of JCA adapters in future.
Atul

Hi Sunit,
I am a little bit confused as to what type of middleware are you referring to. I think you mean custom or propriatary middleware that the legacy application is based on. For example the legacy application may be using MQSeries or other messaging platform to interact with the outside world.
In such cases JCA will enable the J2EE applications to communicate with the middleware and send/receive appropriate application messages.
If you are talking about middleware on the J2EE server like a JMS implementation that is not used by the legacy system then JCA really doesnot interface with the JMS implementation unless it provides access to a legacy system.
I hope I understood your question correctly. Think of JDBC as middleware and a JCA adapter for an accounting package that is based on ODBC, will interface with the JDBC driver. That way the J2EE application doesnot realize that the JCA adapter is actually using JDBC to access the legacy system.
Atul

Ruilin,
A short answer to your question is yes and no. J2EE will do a lot of the work in terms of managing transactions and security, however the JCA adapter will have to implement the contracts specific to transactions (local, distributed) and security. Hence developers still need to code the actual methods which will handle transactions and security between the J2EE server and the EIS (business application).
The run-time management of security and transaction will be done by the J2EE server and so from that perspective developers may have to do very little.
Atul

Hi Tom,
One way to use host emulation or screen scrapping tools or even terminal emulation protocols is to develop a CCI that will support screen interactions.
So if you have an host emulator that has a well defined protocol you could extract a lot of meta-data as well as screen data before invoking the CCI interface of the JCA adapter.
I would recommend that you evaluate stronger integrate frameworks that will enable you to link the host emulator to the JCA adapter (CCI).
Remember you may have to do this in a bi-directional way (from host emulator to JCA/CCI and JCA to host emulator).
If you want, I can send you a CD with a framework that we built which you may find interesting. Use it to do your research and let me know if you think my thinking is appropriate for your integration scenario.
Atul

Hi Pho,
I don't know of any open source SAP resource adapter atleast now. Perhaps there will be in the near future.
Developing a SAP resource adapter will require domain knowledge about SAP as well as proper scope management in terms of which SAP applications you want to interface with and the choice of interface mechanism. Remember SAP and other ERP and large packages have more than one channels or access mechanisms to enable integration.
And once you have an adapter you need to certify it by testing the adapter with SAP systems and keep it updated as SAP applications change in the future.
Also, the SAP adapter needs to support customization of SAP systems at the customers site.
These are just some of the things that you need to keep an eye on. In my book I have a chapter on project management aspects of adapter development and that may help you as well.
Regards
Atul
[ May 01, 2002: Message edited by: Atul Apte ]
[ May 01, 2002: Message edited by: Atul Apte ]