This week's book giveaway is in the Other Open Source APIs forum. We're giving away four copies of Storm Applied and have Sean Allen, Peter Pathirana & Matthew Jankowski on-line! See this thread for details.
Web services are supposed to be stateless - maintaining any kind of state adversely affects scalability of the service. That doesn't mean that you cannot interact with long-running transactions through web services. It simply means that the state is stored somewhere else (like a database) other than the service. To identify which "state" the service is operating on, you have to include a correlation identifier in every message that follows the initial request that initiates the "conversation".
Given what you have outlined I think that the resource connector is the better solution in your case. It should give better performance than a web service and you can always expose the functionality supported by the connector through a web service hosted within the application server. However the connector needs to be designed carefully. If state is stored within the connector then you need server affinity support because all the request of the same "conversation" (with the same correlation identifier) need to be routed to the same server within a cluster. If you can store the state on the EIS any connector instance on any server will do.
Joined: Oct 22, 2007
thanks. Do you know of any good RA resources on the net?