WS-DM adapter for QMan

[Andrea Gazzarini <a....@gmail.com>]

Hi all,
Considering that final goal of QMan is to expose remote broker(s)
management through a standard and language-independent interface, what
do you think about the following options?

- WS-DM adapter will be developed as a JCA (1.5) inbound connector
- WS-DM adapter will be developed as a plain JMX connector;

The advantages of the first option are basically the preexisting
capabilities offered by the JEE infrastructure (transactions,
security, pooling, etc...) but in this way the connector will be
available only when QMan is deployed on a JEE 1.3 (or higher)
container
For the second options the JMX connector should be deployed basically
"from scratch" :( and therefore could have a high level of
customization

I've done some search on internet and I found.  Something similar only
on IBM web site: I don't know exactly but it seems they followed the
first scenario

Please let me know what is your opinion about that

Regards,
Andrea

Re: WS-DM adapter for QMan

[Robert Greig <ro...@gmail.com>]

2008/11/11 Andrea Gazzarini <a....@gmail.com>:

> 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 ....
> :) )

Sounds excellent to me.

Thanks,
RG

Re: WS-DM adapter for QMan

[Andrea Gazzarini <a....@gmail.com>]

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 <cc...@redhat.com>

> Robert Greig wrote:
>
>> 2008/11/10 Andrea Gazzarini <a....@gmail.com>:
>>
>>
>>
>>> 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.
>
>
>

Re: WS-DM adapter for QMan

[Carl Trieloff <cc...@redhat.com>]

Robert Greig wrote:
> 2008/11/10 Andrea Gazzarini <a....@gmail.com>:
>
>   
>> 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.

Re: WS-DM adapter for QMan

[Robert Greig <ro...@gmail.com>]

2008/11/10 Andrea Gazzarini <a....@gmail.com>:

> 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

Re: WS-DM adapter for QMan

[Andrea Gazzarini <a....@gmail.com>]

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 <ro...@gmail.com>

> 2008/11/9 Andrea Gazzarini <a....@gmail.com>:
>
> > 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
>

Re: WS-DM adapter for QMan

[Robert Greig <ro...@gmail.com>]

2008/11/9 Andrea Gazzarini <a....@gmail.com>:

> 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

Re: WS-DM adapter for QMan

[Andrea Gazzarini <a....@gmail.com>]

Hi Paul, thanks for reply.No,basically I don't know if I need a servlet
engine.
This idea cames up to my mind because I saw that the Apache Muse is building
a .war as deliverable and therefore in order to use it I need a servlet
container.
Otherwise I don't know how to install the muse built WS-DM (layer) module on
a standalone axis.

Regards,
Andrea

2008/11/10 Paul Fremantle <pz...@gmail.com>

> Andrea
>
> Axis2 has a built in HTTP server, including a high-performance NIO
> based one, so you don't need a servlet container if you don't want
> one. Alternatively, Jetty is small and embeddable.
>
> Paul
>
> On Mon, Nov 10, 2008 at 11:55 AM, Andrea Gazzarini
> <a....@gmail.com> wrote:
> > Hi Arnaud, we thought the same thing...just a moment please read the
> > following :
> > I was just having a look to apache muse and it seems that they have
> > something we need.The problem is that the final artifacts is something
> > deployable on a web server....but at this point I think it's the only
> > way....WS-DM is an application protocol over SOAP so, if you want to use
> it
> > (SOAP) over HTTP (and we want because SOAP / RMI is still a java coupled
> > solution) you need a HTTP Server and  a servlet engine (i.e. web services
> > engine)
> >
> > As proof of that Muse is using its layer for WS-DM and relying on
> > preexisting Axis2 for web service
> >
> > I'm continuing to investigate...
> >
> > Thanks for reply
> >
> > Regards,
> > Andrea
> >
> > 2008/11/10 Arnaud Simon <as...@redhat.com>
> >
> >> Hi Andrea,
> >>
> >> Would it be possible to do 2) then 1) ? I.E. could we extend 2) so to
> >> achieve 1)?
> >>
> >> Arnaud
> >>
> >> ----- "Andrea Gazzarini" <a....@gmail.com> wrote:
> >>
> >> > Hi all,
> >> > Considering that final goal of QMan is to expose remote broker(s)
> >> > management through a standard and language-independent interface,
> >> > what
> >> > do you think about the following options?
> >> >
> >> > - WS-DM adapter will be developed as a JCA (1.5) inbound connector
> >> > - WS-DM adapter will be developed as a plain JMX connector;
> >> >
> >> > The advantages of the first option are basically the preexisting
> >> > capabilities offered by the JEE infrastructure (transactions,
> >> > security, pooling, etc...) but in this way the connector will be
> >> > available only when QMan is deployed on a JEE 1.3 (or higher)
> >> > container
> >> > For the second options the JMX connector should be deployed basically
> >> > "from scratch" :( and therefore could have a high level of
> >> > customization
> >> >
> >> > I've done some search on internet and I found.  Something similar
> >> > only
> >> > on IBM web site: I don't know exactly but it seems they followed the
> >> > first scenario
> >> >
> >> > Please let me know what is your opinion about that
> >> >
> >> > Regards,
> >> > Andrea
> >>
> >
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>

Re: WS-DM adapter for QMan

[Paul Fremantle <pz...@gmail.com>]

Andrea

Axis2 has a built in HTTP server, including a high-performance NIO
based one, so you don't need a servlet container if you don't want
one. Alternatively, Jetty is small and embeddable.

Paul

On Mon, Nov 10, 2008 at 11:55 AM, Andrea Gazzarini
<a....@gmail.com> wrote:
> Hi Arnaud, we thought the same thing...just a moment please read the
> following :
> I was just having a look to apache muse and it seems that they have
> something we need.The problem is that the final artifacts is something
> deployable on a web server....but at this point I think it's the only
> way....WS-DM is an application protocol over SOAP so, if you want to use it
> (SOAP) over HTTP (and we want because SOAP / RMI is still a java coupled
> solution) you need a HTTP Server and  a servlet engine (i.e. web services
> engine)
>
> As proof of that Muse is using its layer for WS-DM and relying on
> preexisting Axis2 for web service
>
> I'm continuing to investigate...
>
> Thanks for reply
>
> Regards,
> Andrea
>
> 2008/11/10 Arnaud Simon <as...@redhat.com>
>
>> Hi Andrea,
>>
>> Would it be possible to do 2) then 1) ? I.E. could we extend 2) so to
>> achieve 1)?
>>
>> Arnaud
>>
>> ----- "Andrea Gazzarini" <a....@gmail.com> wrote:
>>
>> > Hi all,
>> > Considering that final goal of QMan is to expose remote broker(s)
>> > management through a standard and language-independent interface,
>> > what
>> > do you think about the following options?
>> >
>> > - WS-DM adapter will be developed as a JCA (1.5) inbound connector
>> > - WS-DM adapter will be developed as a plain JMX connector;
>> >
>> > The advantages of the first option are basically the preexisting
>> > capabilities offered by the JEE infrastructure (transactions,
>> > security, pooling, etc...) but in this way the connector will be
>> > available only when QMan is deployed on a JEE 1.3 (or higher)
>> > container
>> > For the second options the JMX connector should be deployed basically
>> > "from scratch" :( and therefore could have a high level of
>> > customization
>> >
>> > I've done some search on internet and I found.  Something similar
>> > only
>> > on IBM web site: I don't know exactly but it seems they followed the
>> > first scenario
>> >
>> > Please let me know what is your opinion about that
>> >
>> > Regards,
>> > Andrea
>>
>



-- 
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

Re: WS-DM adapter for QMan

[Andrea Gazzarini <a....@gmail.com>]

Hi Arnaud, we thought the same thing...just a moment please read the
following :
I was just having a look to apache muse and it seems that they have
something we need.The problem is that the final artifacts is something
deployable on a web server....but at this point I think it's the only
way....WS-DM is an application protocol over SOAP so, if you want to use it
(SOAP) over HTTP (and we want because SOAP / RMI is still a java coupled
solution) you need a HTTP Server and  a servlet engine (i.e. web services
engine)

As proof of that Muse is using its layer for WS-DM and relying on
preexisting Axis2 for web service

I'm continuing to investigate...

Thanks for reply

Regards,
Andrea

2008/11/10 Arnaud Simon <as...@redhat.com>

> Hi Andrea,
>
> Would it be possible to do 2) then 1) ? I.E. could we extend 2) so to
> achieve 1)?
>
> Arnaud
>
> ----- "Andrea Gazzarini" <a....@gmail.com> wrote:
>
> > Hi all,
> > Considering that final goal of QMan is to expose remote broker(s)
> > management through a standard and language-independent interface,
> > what
> > do you think about the following options?
> >
> > - WS-DM adapter will be developed as a JCA (1.5) inbound connector
> > - WS-DM adapter will be developed as a plain JMX connector;
> >
> > The advantages of the first option are basically the preexisting
> > capabilities offered by the JEE infrastructure (transactions,
> > security, pooling, etc...) but in this way the connector will be
> > available only when QMan is deployed on a JEE 1.3 (or higher)
> > container
> > For the second options the JMX connector should be deployed basically
> > "from scratch" :( and therefore could have a high level of
> > customization
> >
> > I've done some search on internet and I found.  Something similar
> > only
> > on IBM web site: I don't know exactly but it seems they followed the
> > first scenario
> >
> > Please let me know what is your opinion about that
> >
> > Regards,
> > Andrea
>

Re: WS-DM adapter for QMan

[Arnaud Simon <as...@redhat.com>]

Hi Andrea,

Would it be possible to do 2) then 1) ? I.E. could we extend 2) so to achieve 1)?

Arnaud

----- "Andrea Gazzarini" <a....@gmail.com> wrote:

> Hi all,
> Considering that final goal of QMan is to expose remote broker(s)
> management through a standard and language-independent interface,
> what
> do you think about the following options?
> 
> - WS-DM adapter will be developed as a JCA (1.5) inbound connector
> - WS-DM adapter will be developed as a plain JMX connector;
> 
> The advantages of the first option are basically the preexisting
> capabilities offered by the JEE infrastructure (transactions,
> security, pooling, etc...) but in this way the connector will be
> available only when QMan is deployed on a JEE 1.3 (or higher)
> container
> For the second options the JMX connector should be deployed basically
> "from scratch" :( and therefore could have a high level of
> customization
> 
> I've done some search on internet and I found.  Something similar
> only
> on IBM web site: I don't know exactly but it seems they followed the
> first scenario
> 
> Please let me know what is your opinion about that
> 
> Regards,
> Andrea