You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Hossam Karim <hr...@gmail.com> on 2006/04/02 02:41:54 UTC
RE: Dynamically adding and removing http endpoints
Guillaume,
Can this be done in a generic way, so that it is only limited by the
number of protocols supported by SM? I mean can this be done so that a
single BC acts as a proxy for all SM services and this BC can accept some
kind of configuration to dynamically publish the endpoint, unpack the
content and then route it through the NMR?
-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com]
Sent: Friday, March 31, 2006 4:55 PM
To: servicemix-users@geronimo.apache.org
Subject: Re: Dynamically adding and removing http endpoints
It would be a standard jbi endpoint acting as a provider. I would
create it within the http component for simplicity, but this does not
mean that this endpoint can not be exposed over any transport: you can
still deploy a proxy endpoint for http, http+soap or any other
transport. The main benefit is that the endpoint would also be
exposed from within the jbi bus.
Cheers,
Guillaume Nodet
On 3/31/06, Stefan Klinger <kl...@cs.york.ac.uk> wrote:
> Thanks, I think I do understand now. Just to recap, the JBI management
> endpoint would be a consumer endpoint of my http-component. What form
> would the JBI endpoint have? I guess that it should be another generic
> JBI component that takes care of the creation/ destruction of other jbi
> service units/ endpoints and external endpoints. Or is that done within
> the http-component itself? I would prefer another component as it can be
> exposed using wsdl and http+soap...
>
> Stefan
>
> Guillaume Nodet wrote:
>
> >I guess I was not very clear.
> >I was only talking about the fact that the http component would create
> >a management JBI endpoint. This endpoint would receive requests to
> >create / destroy endpoints. For a consumer endpoint, just giving the
> >service name / endpoint name of the target endpoint should be
> >sufficient. For a provider endpoint (for example an external web
> >service), the wsdl url should be fine.
> >There is no deployment of SU involved here.
> >Btw, I guess we may also relate this to auto-discovery of services via
UDDI.
> >
> >James just suggested another method for REST endpoints (soap endpoints
> >could use WS-Addressing as a workaround). The http component would
> >create an http consumer endpoint and the http request url would be
> >encoded in such a way that it could retrieve the target destination
> >and send the jbi exchange to it.
> >For example,
> > http://localhost:8080/jbi/com/foo/bar
> >may be mapped to {http://com.foo}bar service.
> >I 'm not sure what's the best way to encode such url. This could also
> >apply to jms component.
> >
> >The standard way however is the one you mentioned (using xbean or wsdl
> >deployment), but you first talk about a programmatic way to do that...
> >
> >Cheers,
> >Guillaume Nodet
> >
> >On 3/31/06, Stefan Klinger <kl...@cs.york.ac.uk> wrote:
> >
> >
> >>Guillaume,
> >>
> >>Initialising from wsdl is fine, but in the current state, I would have
> >>to generate the wsdl on-the-fly, save it to a file which is then picked
> >>up by the Deployer. I just wondered, wouldn't it be much easier, if I
> >>just generated the service units with the (http)-endpoints and register
> >>them with the (http)-component? Removing endpoints would just be the
> >>case of de-registering the service-units from the (http)-component. Or
> >>have I missed something?
> >>
> >>Thanks,
> >>Stefan
> >>
> >>Guillaume Nodet wrote:
> >>
> >>
> >>
> >>>I guess this is exactly what
> >>>http://issues.apache.org/activemq/browse/SM-283 is about.
> >>>
> >>>I would really do that as a jbi endpoint with a wsdl (that could be
> >>>exposed over http of course). I think the wsdl should not be specific
> >>>to the http component (if possible) so that the same wsdl can be used
> >>>for other BCs. If you add a method on the interface to check if a
> >>>protocol is supported, you could easily discover all BC in the bus and
> >>>ask them to create a proxy endpoint. Protocol could be some simple
> >>>string like "http", "jms" (maybe "http+soap" ?). All BCs may need
> >>>some default parameters so that just the JBI endpoint would be
> >>>sufficient to create the proxy endpoint.
> >>>
> >>>Cheers,
> >>>Guillaume Nodet
> >>>
> >>>On 3/30/06, Stefan Klinger <kl...@cs.york.ac.uk> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Hello,
> >>>>
> >>>>I just wondered what the best way is to add and remove http endpoints
> >>>>dynamically online. I know that you can deploy them using either wsdl
or
> >>>>xbean, but is there also a way to do this programmatically while SM is
> >>>>running? I would like to expose this functionality via a web service
> >>>>which other web service providers can access to add/ remove themselves
> >>>>as provider endpoints for SM.
> >>>>
> >>>>Thanks,
> >>>>Stefan
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
>
>
RE: Dynamically adding and removing http endpoints
Posted by Hossam Karim <hr...@gmail.com>.
What I mean exactly is that a core service should be independent of the
protocol. James proposal is innovative; I really didn't think of that, but I
think this might require the client awareness of the meta-information you
mentioned, like providing some key-value pairs when posting to an HTTP
endpoint. Consider a client application 'A' that is not able to communicate
through web services but it can easily consume a JMS queue, while client 'B'
can only send an SMS message. Both 'A' and 'B' are performing a transaction
of some kind and we do have a service engine that can perform the logic. Now
we can have a proxy BC that can be configured to expose endpoints for 'A'
and 'B', use the protocol APIs to extract the content of the message,
normalize it and then route it to the service engine. The BC is exposing a
WSDL for each endpoint it dynamically provides, and the client is only
concerned about the contract not the implementation, so the BC can act as a
group of abstract adapters to the SE. This would still need a SU deployment.
Doing so, we will have full control over lifecycles, addressing (including
MEPs), routing, transport protocol and security. In fact, the BC as well
does not need to address a specific service; it only needs to address an
interface.
We can also get some scalability benefits from such approach, like providing
multiple targets for a single endpoint, so that SM can perform multiple
tasks using a single message.
I hope I was clear, but if you need to see some research implementation in
this area, please tell me, so I can ask my management to share it.
I have an entry about the subject here as well:
http://www.egjug.org/Applying_JBI
Thanks,
Hossam Karim
-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com]
Sent: Sunday, April 02, 2006 12:17 PM
To: servicemix-users@geronimo.apache.org
Subject: Re: Dynamically adding and removing http endpoints
I had in mind that each BC would expose such a management endpoint
that would implement the same wsdl interface so that they all
management endpoints can be queried with the jbi apis. I guess that
the interface would have a method to know what protocols each BC
supports. In addition, I think that SEs could accept some deployment
information for a given endpoint so that it will query the BCs for the
needed protocols and register proxy endpoints for the service.
I 'm not sure to understand when you say "unpack the content and then
route it through the NMR" ... Are you talking about a single BC that
would accept all SU and redirect the deployment to the right BC ? I
was talking about leveraging the need to deploy proxy endpoint.
In addition, what James proposed was that each BC / protocol expose an
external endpoint where the request could be routed a given service by
providing some meta-information (for ex. in the jms queue name, or in
the http request url). This main benefit is that you do not have to
deploy a SU for a proxy endpoint. I guess both proposals are somewhat
similar in this point, so I'm still uncertain about the one ServiceMix
should implement...
Cheers,
Guillaume Nodet
On 4/2/06, Hossam Karim <hr...@gmail.com> wrote:
> Guillaume,
> Can this be done in a generic way, so that it is only limited by the
> number of protocols supported by SM? I mean can this be done so that a
> single BC acts as a proxy for all SM services and this BC can accept some
> kind of configuration to dynamically publish the endpoint, unpack the
> content and then route it through the NMR?
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: Friday, March 31, 2006 4:55 PM
> To: servicemix-users@geronimo.apache.org
> Subject: Re: Dynamically adding and removing http endpoints
>
> It would be a standard jbi endpoint acting as a provider. I would
> create it within the http component for simplicity, but this does not
> mean that this endpoint can not be exposed over any transport: you can
> still deploy a proxy endpoint for http, http+soap or any other
> transport. The main benefit is that the endpoint would also be
> exposed from within the jbi bus.
>
> Cheers,
> Guillaume Nodet
>
> On 3/31/06, Stefan Klinger <kl...@cs.york.ac.uk> wrote:
> > Thanks, I think I do understand now. Just to recap, the JBI management
> > endpoint would be a consumer endpoint of my http-component. What form
> > would the JBI endpoint have? I guess that it should be another generic
> > JBI component that takes care of the creation/ destruction of other jbi
> > service units/ endpoints and external endpoints. Or is that done within
> > the http-component itself? I would prefer another component as it can be
> > exposed using wsdl and http+soap...
> >
> > Stefan
> >
> > Guillaume Nodet wrote:
> >
> > >I guess I was not very clear.
> > >I was only talking about the fact that the http component would create
> > >a management JBI endpoint. This endpoint would receive requests to
> > >create / destroy endpoints. For a consumer endpoint, just giving the
> > >service name / endpoint name of the target endpoint should be
> > >sufficient. For a provider endpoint (for example an external web
> > >service), the wsdl url should be fine.
> > >There is no deployment of SU involved here.
> > >Btw, I guess we may also relate this to auto-discovery of services via
> UDDI.
> > >
> > >James just suggested another method for REST endpoints (soap endpoints
> > >could use WS-Addressing as a workaround). The http component would
> > >create an http consumer endpoint and the http request url would be
> > >encoded in such a way that it could retrieve the target destination
> > >and send the jbi exchange to it.
> > >For example,
> > > http://localhost:8080/jbi/com/foo/bar
> > >may be mapped to {http://com.foo}bar service.
> > >I 'm not sure what's the best way to encode such url. This could also
> > >apply to jms component.
> > >
> > >The standard way however is the one you mentioned (using xbean or wsdl
> > >deployment), but you first talk about a programmatic way to do that...
> > >
> > >Cheers,
> > >Guillaume Nodet
> > >
> > >On 3/31/06, Stefan Klinger <kl...@cs.york.ac.uk> wrote:
> > >
> > >
> > >>Guillaume,
> > >>
> > >>Initialising from wsdl is fine, but in the current state, I would have
> > >>to generate the wsdl on-the-fly, save it to a file which is then
picked
> > >>up by the Deployer. I just wondered, wouldn't it be much easier, if I
> > >>just generated the service units with the (http)-endpoints and
register
> > >>them with the (http)-component? Removing endpoints would just be the
> > >>case of de-registering the service-units from the (http)-component. Or
> > >>have I missed something?
> > >>
> > >>Thanks,
> > >>Stefan
> > >>
> > >>Guillaume Nodet wrote:
> > >>
> > >>
> > >>
> > >>>I guess this is exactly what
> > >>>http://issues.apache.org/activemq/browse/SM-283 is about.
> > >>>
> > >>>I would really do that as a jbi endpoint with a wsdl (that could be
> > >>>exposed over http of course). I think the wsdl should not be
specific
> > >>>to the http component (if possible) so that the same wsdl can be used
> > >>>for other BCs. If you add a method on the interface to check if a
> > >>>protocol is supported, you could easily discover all BC in the bus
and
> > >>>ask them to create a proxy endpoint. Protocol could be some simple
> > >>>string like "http", "jms" (maybe "http+soap" ?). All BCs may need
> > >>>some default parameters so that just the JBI endpoint would be
> > >>>sufficient to create the proxy endpoint.
> > >>>
> > >>>Cheers,
> > >>>Guillaume Nodet
> > >>>
> > >>>On 3/30/06, Stefan Klinger <kl...@cs.york.ac.uk> wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>Hello,
> > >>>>
> > >>>>I just wondered what the best way is to add and remove http
endpoints
> > >>>>dynamically online. I know that you can deploy them using either
wsdl
> or
> > >>>>xbean, but is there also a way to do this programmatically while SM
is
> > >>>>running? I would like to expose this functionality via a web service
> > >>>>which other web service providers can access to add/ remove
themselves
> > >>>>as provider endpoints for SM.
> > >>>>
> > >>>>Thanks,
> > >>>>Stefan
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> >
> >
>
>
Re: Dynamically adding and removing http endpoints
Posted by Guillaume Nodet <gn...@gmail.com>.
I had in mind that each BC would expose such a management endpoint
that would implement the same wsdl interface so that they all
management endpoints can be queried with the jbi apis. I guess that
the interface would have a method to know what protocols each BC
supports. In addition, I think that SEs could accept some deployment
information for a given endpoint so that it will query the BCs for the
needed protocols and register proxy endpoints for the service.
I 'm not sure to understand when you say "unpack the content and then
route it through the NMR" ... Are you talking about a single BC that
would accept all SU and redirect the deployment to the right BC ? I
was talking about leveraging the need to deploy proxy endpoint.
In addition, what James proposed was that each BC / protocol expose an
external endpoint where the request could be routed a given service by
providing some meta-information (for ex. in the jms queue name, or in
the http request url). This main benefit is that you do not have to
deploy a SU for a proxy endpoint. I guess both proposals are somewhat
similar in this point, so I'm still uncertain about the one ServiceMix
should implement...
Cheers,
Guillaume Nodet
On 4/2/06, Hossam Karim <hr...@gmail.com> wrote:
> Guillaume,
> Can this be done in a generic way, so that it is only limited by the
> number of protocols supported by SM? I mean can this be done so that a
> single BC acts as a proxy for all SM services and this BC can accept some
> kind of configuration to dynamically publish the endpoint, unpack the
> content and then route it through the NMR?
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: Friday, March 31, 2006 4:55 PM
> To: servicemix-users@geronimo.apache.org
> Subject: Re: Dynamically adding and removing http endpoints
>
> It would be a standard jbi endpoint acting as a provider. I would
> create it within the http component for simplicity, but this does not
> mean that this endpoint can not be exposed over any transport: you can
> still deploy a proxy endpoint for http, http+soap or any other
> transport. The main benefit is that the endpoint would also be
> exposed from within the jbi bus.
>
> Cheers,
> Guillaume Nodet
>
> On 3/31/06, Stefan Klinger <kl...@cs.york.ac.uk> wrote:
> > Thanks, I think I do understand now. Just to recap, the JBI management
> > endpoint would be a consumer endpoint of my http-component. What form
> > would the JBI endpoint have? I guess that it should be another generic
> > JBI component that takes care of the creation/ destruction of other jbi
> > service units/ endpoints and external endpoints. Or is that done within
> > the http-component itself? I would prefer another component as it can be
> > exposed using wsdl and http+soap...
> >
> > Stefan
> >
> > Guillaume Nodet wrote:
> >
> > >I guess I was not very clear.
> > >I was only talking about the fact that the http component would create
> > >a management JBI endpoint. This endpoint would receive requests to
> > >create / destroy endpoints. For a consumer endpoint, just giving the
> > >service name / endpoint name of the target endpoint should be
> > >sufficient. For a provider endpoint (for example an external web
> > >service), the wsdl url should be fine.
> > >There is no deployment of SU involved here.
> > >Btw, I guess we may also relate this to auto-discovery of services via
> UDDI.
> > >
> > >James just suggested another method for REST endpoints (soap endpoints
> > >could use WS-Addressing as a workaround). The http component would
> > >create an http consumer endpoint and the http request url would be
> > >encoded in such a way that it could retrieve the target destination
> > >and send the jbi exchange to it.
> > >For example,
> > > http://localhost:8080/jbi/com/foo/bar
> > >may be mapped to {http://com.foo}bar service.
> > >I 'm not sure what's the best way to encode such url. This could also
> > >apply to jms component.
> > >
> > >The standard way however is the one you mentioned (using xbean or wsdl
> > >deployment), but you first talk about a programmatic way to do that...
> > >
> > >Cheers,
> > >Guillaume Nodet
> > >
> > >On 3/31/06, Stefan Klinger <kl...@cs.york.ac.uk> wrote:
> > >
> > >
> > >>Guillaume,
> > >>
> > >>Initialising from wsdl is fine, but in the current state, I would have
> > >>to generate the wsdl on-the-fly, save it to a file which is then picked
> > >>up by the Deployer. I just wondered, wouldn't it be much easier, if I
> > >>just generated the service units with the (http)-endpoints and register
> > >>them with the (http)-component? Removing endpoints would just be the
> > >>case of de-registering the service-units from the (http)-component. Or
> > >>have I missed something?
> > >>
> > >>Thanks,
> > >>Stefan
> > >>
> > >>Guillaume Nodet wrote:
> > >>
> > >>
> > >>
> > >>>I guess this is exactly what
> > >>>http://issues.apache.org/activemq/browse/SM-283 is about.
> > >>>
> > >>>I would really do that as a jbi endpoint with a wsdl (that could be
> > >>>exposed over http of course). I think the wsdl should not be specific
> > >>>to the http component (if possible) so that the same wsdl can be used
> > >>>for other BCs. If you add a method on the interface to check if a
> > >>>protocol is supported, you could easily discover all BC in the bus and
> > >>>ask them to create a proxy endpoint. Protocol could be some simple
> > >>>string like "http", "jms" (maybe "http+soap" ?). All BCs may need
> > >>>some default parameters so that just the JBI endpoint would be
> > >>>sufficient to create the proxy endpoint.
> > >>>
> > >>>Cheers,
> > >>>Guillaume Nodet
> > >>>
> > >>>On 3/30/06, Stefan Klinger <kl...@cs.york.ac.uk> wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>Hello,
> > >>>>
> > >>>>I just wondered what the best way is to add and remove http endpoints
> > >>>>dynamically online. I know that you can deploy them using either wsdl
> or
> > >>>>xbean, but is there also a way to do this programmatically while SM is
> > >>>>running? I would like to expose this functionality via a web service
> > >>>>which other web service providers can access to add/ remove themselves
> > >>>>as provider endpoints for SM.
> > >>>>
> > >>>>Thanks,
> > >>>>Stefan
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> >
> >
>
>