Ok, and I agree with you. Just to be clear because I made a lot of confusion
with this post :
the choice was basically between a "managed" and "non-managed" component.
I mentioned JCA Inbound connector because they are usually the natural way
to extend the "connectivity" of your application server (adding for example
support for a new protocol i.e. Diameter).
@Robert : you're right, a JCA Connector requires a JCA Container that is
avalable only on an application server. Anyway the description you reported
("or cases where you need to connect to a transactional service") better fit
for JCA "outbound" connectors.
Now, returning to the original choice perspective, there's no difference
between using a JCA or a Servlet becuase both of them are managed components
(the first requires a JCA container while the second requires a web
container).
So, end of the riepilogue, the final deliverable (if I understood) should
be:
- a web application ; and here the integration using a servlet should be
simple because we are already using a servlet inside the application;
- standalone : in this context no web container is available so as you
suggest we could embbed in the bundle Jetty or something similar. So also
here we are developing a web application (which contains its container ....
:) )
Regards,
Andrea
2008/11/10 Carl Trieloff <[EMAIL PROTECTED]>
> 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.
>
>
>
