Robert Greig wrote:
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
Agree, lets stay away from JCA for now if we can do servlet, I would say
that is better
Carl.
