This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I have any doubts about DAO pattern. Here is an extract from JEE pattern, DAO - Solution :
.. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, a repository like an LDAP database, or a business service accessed via CORBA Internet Inter-ORB Protocol (IIOP) or low-level sockets. ... Essentially, the DAO acts as an adapter between the component and the data source.
So I think DAO is the best suited pattern in integration tier to access external system. I read any posts saying that adapter or proxy is better than DAO to access a web service, but DAO is a kind of adapter. In cade's book, DAO components access mail server, inventory system, LDAP server...
1) Is DOA the only pattern to use in integration tier?
Still in JEE pattern, DAO solution :
Because the interface exposed by the DAO to clients does not change when the underlying data source implementation changes, this pattern allows the DAO to adapt to different storage schemes without affecting its clients or business components.
Essentially,I use DAO to access database and it makes sense.
But I'm thinking using DAO to access messaging system and I have any troubles with this :
- if my DAO exposes a synchronous interface and deals with request-reply integration pattern to communicate with messaging system, DAO exposes an independant implementation interface to client. The problem : when the client makes several calls to external system, it calls sequentially DAO methods while messaging system could accept parrallels requests. I loose the advantage of using a messaging system.
- if my DAO exposes a asynchronous interface, it exposes the fact that underlaying system is asynchronous.
With JavaEE 6, asynchronous session bean returning Future object might be the solution, but both DAOs dealing with synchronous and asynchronous system should return Future instance. This way, we can switch from synchronous system to asynchronous system with no change on DAO interface.
It's weird, isn't it?
What do you thing about points 1/ & 2/?
Is it something I misunderstood?
What is your solution for messaging system?
While a DAO could access anything, I consider the intent. If i am doing async messaging, I'm not doing data access. If you keep in mind that DAO stands for data access object, it gives a good feel for when it is appropriate. LDAP makes sense to me. Email does not.