2008/11/10 Andrea Gazzarini <[EMAIL PROTECTED]>: > 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...
Hi Andrea, I think my question is really about what the advantages of a JCA connector over a servlet? If we have a servlet, we can create a package with something like Jetty or we can allow people to deploy in the app server of their choice (including something like Tomcat that is not a full JEE server). A JCA connector (I think?) requires a full JEE stack. > 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. This would work. But do people need a JCA connector? I had thought (perhaps mistakenly, so do correct me) that JCA connectors were primarily for cases where you need to connect to a transactional service, e.g. CICS. > 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 ); So this would embed Jetty or something similar? RG
