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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: Friday, March 31, 2006 4:55 PM > To: [email protected] > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >> > > >> > > > > > >
