Hi Robert, you're right : the second option is for sure the most flexible. The drawback is that you must assemble / write all the components from scratch while if you write a JEE component it's supposed that the managed environment will take care of all underlying "non-functional" requirements like transaction, security,availability,clustering, load balancing, pooling, etc...I don't know if we need all those aspects but I think that it's hard to assemble / write those from scratch...
In order to be deployable, a component must meet some requirements (i.e. mustn't take care of the above aspects) so I see what you mean...we could try this : A non-JEE connector that implements required "non functional requirements" that is delegating the functional aspects to an iternal component that in turn is a JCA compliant connector. In this way, the build system could be able to build a "standalone" and a JCA connector. The first one (i.e. wsdm-connector.jar) will be used in standalone way so will have a main() that starst the non-JEE connector (and internally it delegates to JCA connector that in this case is not a JEE component ); The second one will be a valid (i.e. wsdm-connector.rar) JCA 1.5 inbound connector deployable on a JEE Application Server. What do you think? Regards, Andrea 2008/11/9 Robert Greig <[EMAIL PROTECTED]> > 2008/11/9 Andrea Gazzarini <[EMAIL PROTECTED]>: > > > Please let me know what is your opinion about that > > Andrea, > > I am not sure, but it seems to me that option (2) is more flexible - > i.e you could deploy it in a JEE container or not. What is the > advantage of (1) over (2)? > > RG >
