You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Rossmanith, Philipp" <ph...@t-systems.es> on 2007/05/17 11:14:18 UTC
RE: Remote deployment of service assemblies
Hi,
After quite a break, I am back with the issue relating to this thread.
What I did was creating a jsr-181 WSDL first service, for which I set a
ComponentContext *). The setup is different from what had been outlined
earlier, as I am creating a service assembly ZIP based on parameters I
receive.
My idea was to obtain a DeliveryChannelImpl from the ComponentContext
and to then follow the steps Guillaume has pointed out below.
However, the ComponentContext that is being set by SM is an
EndpointComponentContext which doesn't give me access to this
information.
Any hints of how I can get hold of the JBIContainer or its
AdminCommandsServiceMBean?
Thanks in advance,
Ciao,
Philipp
*) http://incubator.apache.org/servicemix/servicemix-jsr181.html
**) For the moment, I am creating a service assembly zip file for WSN
subscriptions once the service gets invoked. Parameters are the
wsa:address, the topic and an identifier.
> -----Mensaje original-----
> De: Guillaume Nodet [mailto:gnodet@gmail.com]
> Enviado el: martes, 20 de marzo de 2007 11:21
> Para: servicemix-dev@geronimo.apache.org
> Asunto: Re: Remote deployment of service assemblies
>
> On 3/20/07, Rossmanith, Philipp <ph...@t-systems.es>
wrote:
> >
> >
> > Hi,
> >
> > > Once you have the JBIContainer, just retrieve the needed
interface:
> > > JBIContainer container = dci.getContainer();
> > > AdminCommandsServiceMBean admin =
> > container.getAdminCommandsService();
> > >
> > > Then, you can use it to deploy / undeploy, manage life cycle, etc
..
> > > admin.installComponent()
> > > admin.startComponent()
> > > admin.listServiceAssemblies() ...
> > Ok, that is quite a bit cleaner...
> >
> > > all the administrative tasks are available from this interface, so
I
> > guess
> > > the WSDL
> > > should be quite easy to write. On the implementation side, one
way is
> > to
> > > use
> > > jaxb2 (not the full jsr181 though) as done in the WS-Notification
> > > component.
> > > See org.apache.servicemix.wsn.component.WSNEndpoint class.
> > What I was thinking about was a WSDL wrapper around the
> > AdminCommandsServiceMBean methods.
> >
> > I'm currently investigating the WSN component to use it for
> > notifications based on message content (see
> >
http://www.nabble.com/how-to-implement-runtime-notifications-based-on-Me
> > ssageExchange--content-tf3409844s12049.html), but I must say I'm
afraid
> > I don't really understand your idea (which may be due to my limited
> > experience with jaxb2).
> >
> > It seems to me that the wsn component WSNEndpoint uses the
annotations
> > done in the org.apache.servicemix.wsn.AbstractEndpoint hierarchy (an
> > object of this class is passed in as "pojo" in the constructor) to
> > obtain a class object "endpointInterface" which is then used to get
hold
> > of the methods published in that interface. Jaxb2 seems to be used
to
> > unmarshal incoming normalized message content and to marshal it to
> > outgoing exchanges (method: process).
> >
> > However, if I'm ""only"" writing a provider service and not a
> > full-fledged component, what would be the advantages of the approach
> > taken in WSNEndpoint?
> >
> > Or am I misinterpreting, and you're using jaxb2 for creating a
jsr181
> > code skeleton based on a previously generated WSDL?
>
>
> Yeah, that's the point.
> The WSNEndpoint is used to invoke an annotated POJO generated
> from the WSDL like AbstractNotificationBroker.
> The AbstractNotificationBroker#init method calls register, which
> ultimately
> creates a WSNEndpoint with the AbstractNotificationBroker class as the
> pojo.
>
> So, once the WSDL is written, you can use wsgen to generate the
interfaces
> and messages, create your own POJO implementation and wrap it with
> the WSNEndpoint. (It makes me think that this class may be put in
> servicemix-common).
>
> But this is only one way to do that. Feel free to use your own if you
> prefer.
>
> The last question is how do we package that. I'm thinking about
> a SE, but without any support for deployments of SU,
> I guess another way could be to leverage the JSR181 component and
> just write a SU for it (and another for the http BC i guess).
> The last way would be to configure it directly on the JBI container
> without any JBI packaging ...
> Need to think about pros / cons ...
>
> > .. and discussions about servicemix developement should take place
on
> > the
> > > dev
> > > list ... ;-)
> > Done :-)
>
>
> Thanks in advance,
> > Ciao,
> > Philipp
> >
> > > -----Mensaje original-----
> > > De: Guillaume Nodet [mailto:gnodet@gmail.com]
> > > Enviado el: lunes, 19 de marzo de 2007 16:56
> > > Para: servicemix-users@geronimo.apache.org
> > > Asunto: Re: Remote deployment of service assemblies
> > > Importancia: Baja
> > >
> > > On 3/19/07, Rossmanith, Philipp <ph...@t-systems.es>
> > wrote:
> > > >
> > > >
> > > > > Currently, remote deployment is not supported by the ant
tasks.
> > > > > The only way to do currently that is to start a servicemix
console
> > > > > on the same server, because the console accepts uploads and
will
> > > > > be able to point the container to a local file.
> > > > >
> > > > > The only way using JMX would be to add a method accepting a
byte[]
> > > > > parameter which would be the content of the JBI artifact to
> > deploy, or
> > > > > creating an management endpoint on the JBI bus (using an
> > attachment
> > > > > for the JBI archetype). Not sure what's the best way.
> > > > I was thinking about this alternative, as well. There could be a
> > > > provider service that accepts calls having an SA attachment. It
> > could
> > > > then obtain this attachment and physically place it in the
> > deployment
> > > > dir.
> > >
> > >
> > > Using the hot deployer is imo not the best solution.
> > > We should use the AdminCommandsService instead (see below)
> > >
> > > In that way, one could use the same access control mechanism as
for
> > the
> > > > rest of the service invocations. Another advantage would be that
> > through
> > > > the different binding components, the functionality would be
> > available
> > > > in more than just Java.
> > >
> > >
> > > Yeah, agreed. We just need to define a clean WSDL for it.
> > >
> > > However, I'd need to access some JBIContainer properties, such as
the
> > > > deployment directory. I assume that the best way to obtain
internals
> > > > about the JBI container would be to use the client API
> > > > (http://incubator.apache.org/servicemix/client-api.html).
> > > >
> > > > I could then use the following code:
> > > > >>
> > > > ...
> > > > DeliveryChannelImpl dci = (DeliveryChannelImpl)
> > > > defaultSMClientInstance.getDeliveryChannel();
> > > > JBIContainer container = dci.getContainer();
> > > > ...
> > > > String deploymentDirPath = container.getDeploymentDirPath();
> > > > ...
> > > > <<
> > > >
> > > > However, this hack seems quite (if not: too) dirty. Is there a
more
> > > > elegant solution?
> > >
> > >
> > >
> > > Once you have the JBIContainer, just retrieve the needed
interface:
> > > JBIContainer container = dci.getContainer();
> > > AdminCommandsServiceMBean admin =
> > container.getAdminCommandsService();
> > >
> > > Then, you can use it to deploy / undeploy, manage life cycle, etc
..
> > > admin.installComponent()
> > > admin.startComponent()
> > > admin.listServiceAssemblies() ...
> > >
> > > all the administrative tasks are available from this interface, so
I
> > guess
> > > the WSDL
> > > should be quite easy to write. On the implementation side, one
way is
> > to
> > > use
> > > jaxb2 (not the full jsr181 though) as done in the WS-Notification
> > > component.
> > > See org.apache.servicemix.wsn.component.WSNEndpoint class.
> > >
> > > .. and discussions about servicemix developement should take place
on
> > the
> > > dev
> > > list ... ;-)
> > >
> > > Thanks in advance,
> > > > Ciao,
> > > > Philipp
> > > >
> > > > > -----Mensaje original-----
> > > > > De: Guillaume Nodet [mailto:gnodet@gmail.com]
> > > > > Enviado el: lunes, 19 de marzo de 2007 16:01
> > > > > Para: servicemix-users@geronimo.apache.org
> > > > > Asunto: Re: Remote deployment of service assemblies
> > > > > Importancia: Baja
> > > > >
> > > > > Currently, remote deployment is not supported by the ant
tasks.
> > > > > The only way to do currently that is to start a servicemix
console
> > > > > on the same server, because the console accepts uploads and
will
> > > > > be able to point the container to a local file.
> > > > >
> > > > > The only way using JMX would be to add a method accepting a
byte[]
> > > > > parameter which would be the content of the JBI artifact to
> > deploy, or
> > > > > creating an management endpoint on the JBI bus (using an
> > attachment
> > > > > for the JBI archetype). Not sure what's the best way.
> > > > >
> > > > > On 3/19/07, Rossmanith, Philipp
<ph...@t-systems.es>
> > > > wrote:
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > In our project, we have several client applications that
need to
> > > > deploy
> > > > > > and undeploy service assemblies at runtime. The majority of
them
> > are
> > > > > > written in Java, others not.
> > > > > >
> > > > > > It seems that remote administration is something that would
best
> > be
> > > > > > handled by the administration Ant tasks.
> > > > > >
> > > > > > Ant tasks can be called from Java code:
> > > > > > http://ant.apache.org/manual/antexternal.html
> > > > > >
> > > > > > Now I was wondering:
> > > > > > If I need to do remote un-/deployment from within client
> > > > applications,
> > > > > > is there already some existing API for doing that? Perhaps
an
> > > > Endpoint
> > > > > > accepting service assemblies? If not, would some
Java-wrapper
> > around
> > > > the
> > > > > > aforementioned Ant tasks be a viable alternative?
> > > > > >
> > > > > > Thanks in advance,
> > > > > > Ciao,
> > > > > > Philipp
> > > > > >
> > > > > > This e-mail may contain confidential or privileged
information.
> > Any
> > > > > > unauthorised
> > > > > > copying, use or distribution of this information is strictly
> > > > prohibited.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers,
> > > > > Guillaume Nodet
> > > > > ------------------------
> > > > > Architect, LogicBlaze (http://www.logicblaze.com/)
> > > > > Blog: http://gnodet.blogspot.com/
> > > >
> > > > This e-mail may contain confidential or privileged information.
Any
> > > > unauthorised
> > > > copying, use or distribution of this information is strictly
> > prohibited.
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Architect, LogicBlaze (http://www.logicblaze.com/)
> > > Blog: http://gnodet.blogspot.com/
> >
> > This e-mail may contain confidential or privileged information. Any
> > unauthorised
> > copying, use or distribution of this information is strictly
prohibited.
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Architect, LogicBlaze (http://www.logicblaze.com/)
> Blog: http://gnodet.blogspot.com/
This e-mail may contain confidential or privileged information. Any unauthorised
copying, use or distribution of this information is strictly prohibited.
RE: Remote deployment of service assemblies
Posted by "Rossmanith, Philipp" <ph...@t-systems.es>.
Thanks!
Ciao,
Philipp
> -----Mensaje original-----
> De: Guillaume Nodet [mailto:gnodet@gmail.com]
> Enviado el: jueves, 17 de mayo de 2007 15:21
> Para: servicemix-dev@geronimo.apache.org
> Asunto: Re: Remote deployment of service assemblies
>
> See http://issues.apache.org/activemq/browse/SM-858
> which has been fixed a few weeks ago in trunk.
>
> On 5/17/07, Rossmanith, Philipp <ph...@t-systems.es>
wrote:
> >
> >
> > Hi,
> >
> > After quite a break, I am back with the issue relating to this
thread.
> > What I did was creating a jsr-181 WSDL first service, for which I
set a
> > ComponentContext *). The setup is different from what had been
outlined
> > earlier, as I am creating a service assembly ZIP based on parameters
I
> > receive.
> >
> > My idea was to obtain a DeliveryChannelImpl from the
ComponentContext
> > and to then follow the steps Guillaume has pointed out below.
> >
> > However, the ComponentContext that is being set by SM is an
> > EndpointComponentContext which doesn't give me access to this
> > information.
> >
> > Any hints of how I can get hold of the JBIContainer or its
> > AdminCommandsServiceMBean?
> >
> > Thanks in advance,
> > Ciao,
> > Philipp
> >
> > *) http://incubator.apache.org/servicemix/servicemix-jsr181.html
> > **) For the moment, I am creating a service assembly zip file for
WSN
> > subscriptions once the service gets invoked. Parameters are the
> > wsa:address, the topic and an identifier.
> >
> > > -----Mensaje original-----
> > > De: Guillaume Nodet [mailto:gnodet@gmail.com]
> > > Enviado el: martes, 20 de marzo de 2007 11:21
> > > Para: servicemix-dev@geronimo.apache.org
> > > Asunto: Re: Remote deployment of service assemblies
> > >
> > > On 3/20/07, Rossmanith, Philipp <ph...@t-systems.es>
> > wrote:
> > > >
> > > >
> > > > Hi,
> > > >
> > > > > Once you have the JBIContainer, just retrieve the needed
> > interface:
> > > > > JBIContainer container = dci.getContainer();
> > > > > AdminCommandsServiceMBean admin =
> > > > container.getAdminCommandsService();
> > > > >
> > > > > Then, you can use it to deploy / undeploy, manage life cycle,
etc
> > ..
> > > > > admin.installComponent()
> > > > > admin.startComponent()
> > > > > admin.listServiceAssemblies() ...
> > > > Ok, that is quite a bit cleaner...
> > > >
> > > > > all the administrative tasks are available from this
interface, so
> > I
> > > > guess
> > > > > the WSDL
> > > > > should be quite easy to write. On the implementation side,
one
> > way is
> > > > to
> > > > > use
> > > > > jaxb2 (not the full jsr181 though) as done in the
WS-Notification
> > > > > component.
> > > > > See org.apache.servicemix.wsn.component.WSNEndpoint class.
> > > > What I was thinking about was a WSDL wrapper around the
> > > > AdminCommandsServiceMBean methods.
> > > >
> > > > I'm currently investigating the WSN component to use it for
> > > > notifications based on message content (see
> > > >
> >
http://www.nabble.com/how-to-implement-runtime-notifications-based-on-Me
> > > > ssageExchange--content-tf3409844s12049.html), but I must say I'm
> > afraid
> > > > I don't really understand your idea (which may be due to my
limited
> > > > experience with jaxb2).
> > > >
> > > > It seems to me that the wsn component WSNEndpoint uses the
> > annotations
> > > > done in the org.apache.servicemix.wsn.AbstractEndpoint hierarchy
(an
> > > > object of this class is passed in as "pojo" in the constructor)
to
> > > > obtain a class object "endpointInterface" which is then used to
get
> > hold
> > > > of the methods published in that interface. Jaxb2 seems to be
used
> > to
> > > > unmarshal incoming normalized message content and to marshal it
to
> > > > outgoing exchanges (method: process).
> > > >
> > > > However, if I'm ""only"" writing a provider service and not a
> > > > full-fledged component, what would be the advantages of the
approach
> > > > taken in WSNEndpoint?
> > > >
> > > > Or am I misinterpreting, and you're using jaxb2 for creating a
> > jsr181
> > > > code skeleton based on a previously generated WSDL?
> > >
> > >
> > > Yeah, that's the point.
> > > The WSNEndpoint is used to invoke an annotated POJO generated
> > > from the WSDL like AbstractNotificationBroker.
> > > The AbstractNotificationBroker#init method calls register, which
> > > ultimately
> > > creates a WSNEndpoint with the AbstractNotificationBroker class as
the
> > > pojo.
> > >
> > > So, once the WSDL is written, you can use wsgen to generate the
> > interfaces
> > > and messages, create your own POJO implementation and wrap it with
> > > the WSNEndpoint. (It makes me think that this class may be put in
> > > servicemix-common).
> > >
> > > But this is only one way to do that. Feel free to use your own if
you
> > > prefer.
> > >
> > > The last question is how do we package that. I'm thinking about
> > > a SE, but without any support for deployments of SU,
> > > I guess another way could be to leverage the JSR181 component and
> > > just write a SU for it (and another for the http BC i guess).
> > > The last way would be to configure it directly on the JBI
container
> > > without any JBI packaging ...
> > > Need to think about pros / cons ...
> > >
> > > > .. and discussions about servicemix developement should take
place
> > on
> > > > the
> > > > > dev
> > > > > list ... ;-)
> > > > Done :-)
> > >
> > >
> > > Thanks in advance,
> > > > Ciao,
> > > > Philipp
> > > >
> > > > > -----Mensaje original-----
> > > > > De: Guillaume Nodet [mailto:gnodet@gmail.com]
> > > > > Enviado el: lunes, 19 de marzo de 2007 16:56
> > > > > Para: servicemix-users@geronimo.apache.org
> > > > > Asunto: Re: Remote deployment of service assemblies
> > > > > Importancia: Baja
> > > > >
> > > > > On 3/19/07, Rossmanith, Philipp
<ph...@t-systems.es>
> > > > wrote:
> > > > > >
> > > > > >
> > > > > > > Currently, remote deployment is not supported by the ant
> > tasks.
> > > > > > > The only way to do currently that is to start a servicemix
> > console
> > > > > > > on the same server, because the console accepts uploads
and
> > will
> > > > > > > be able to point the container to a local file.
> > > > > > >
> > > > > > > The only way using JMX would be to add a method accepting
a
> > byte[]
> > > > > > > parameter which would be the content of the JBI artifact
to
> > > > deploy, or
> > > > > > > creating an management endpoint on the JBI bus (using an
> > > > attachment
> > > > > > > for the JBI archetype). Not sure what's the best way.
> > > > > > I was thinking about this alternative, as well. There could
be a
> > > > > > provider service that accepts calls having an SA attachment.
It
> > > > could
> > > > > > then obtain this attachment and physically place it in the
> > > > deployment
> > > > > > dir.
> > > > >
> > > > >
> > > > > Using the hot deployer is imo not the best solution.
> > > > > We should use the AdminCommandsService instead (see below)
> > > > >
> > > > > In that way, one could use the same access control mechanism
as
> > for
> > > > the
> > > > > > rest of the service invocations. Another advantage would be
that
> > > > through
> > > > > > the different binding components, the functionality would be
> > > > available
> > > > > > in more than just Java.
> > > > >
> > > > >
> > > > > Yeah, agreed. We just need to define a clean WSDL for it.
> > > > >
> > > > > However, I'd need to access some JBIContainer properties, such
as
> > the
> > > > > > deployment directory. I assume that the best way to obtain
> > internals
> > > > > > about the JBI container would be to use the client API
> > > > > > (http://incubator.apache.org/servicemix/client-api.html).
> > > > > >
> > > > > > I could then use the following code:
> > > > > > >>
> > > > > > ...
> > > > > > DeliveryChannelImpl dci = (DeliveryChannelImpl)
> > > > > > defaultSMClientInstance.getDeliveryChannel();
> > > > > > JBIContainer container = dci.getContainer();
> > > > > > ...
> > > > > > String deploymentDirPath = container.getDeploymentDirPath();
> > > > > > ...
> > > > > > <<
> > > > > >
> > > > > > However, this hack seems quite (if not: too) dirty. Is there
a
> > more
> > > > > > elegant solution?
> > > > >
> > > > >
> > > > >
> > > > > Once you have the JBIContainer, just retrieve the needed
> > interface:
> > > > > JBIContainer container = dci.getContainer();
> > > > > AdminCommandsServiceMBean admin =
> > > > container.getAdminCommandsService();
> > > > >
> > > > > Then, you can use it to deploy / undeploy, manage life cycle,
etc
> > ..
> > > > > admin.installComponent()
> > > > > admin.startComponent()
> > > > > admin.listServiceAssemblies() ...
> > > > >
> > > > > all the administrative tasks are available from this
interface, so
> > I
> > > > guess
> > > > > the WSDL
> > > > > should be quite easy to write. On the implementation side,
one
> > way is
> > > > to
> > > > > use
> > > > > jaxb2 (not the full jsr181 though) as done in the
WS-Notification
> > > > > component.
> > > > > See org.apache.servicemix.wsn.component.WSNEndpoint class.
> > > > >
> > > > > .. and discussions about servicemix developement should take
place
> > on
> > > > the
> > > > > dev
> > > > > list ... ;-)
> > > > >
> > > > > Thanks in advance,
> > > > > > Ciao,
> > > > > > Philipp
> > > > > >
> > > > > > > -----Mensaje original-----
> > > > > > > De: Guillaume Nodet [mailto:gnodet@gmail.com]
> > > > > > > Enviado el: lunes, 19 de marzo de 2007 16:01
> > > > > > > Para: servicemix-users@geronimo.apache.org
> > > > > > > Asunto: Re: Remote deployment of service assemblies
> > > > > > > Importancia: Baja
> > > > > > >
> > > > > > > Currently, remote deployment is not supported by the ant
> > tasks.
> > > > > > > The only way to do currently that is to start a servicemix
> > console
> > > > > > > on the same server, because the console accepts uploads
and
> > will
> > > > > > > be able to point the container to a local file.
> > > > > > >
> > > > > > > The only way using JMX would be to add a method accepting
a
> > byte[]
> > > > > > > parameter which would be the content of the JBI artifact
to
> > > > deploy, or
> > > > > > > creating an management endpoint on the JBI bus (using an
> > > > attachment
> > > > > > > for the JBI archetype). Not sure what's the best way.
> > > > > > >
> > > > > > > On 3/19/07, Rossmanith, Philipp
> > <ph...@t-systems.es>
> > > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > In our project, we have several client applications that
> > need to
> > > > > > deploy
> > > > > > > > and undeploy service assemblies at runtime. The majority
of
> > them
> > > > are
> > > > > > > > written in Java, others not.
> > > > > > > >
> > > > > > > > It seems that remote administration is something that
would
> > best
> > > > be
> > > > > > > > handled by the administration Ant tasks.
> > > > > > > >
> > > > > > > > Ant tasks can be called from Java code:
> > > > > > > > http://ant.apache.org/manual/antexternal.html
> > > > > > > >
> > > > > > > > Now I was wondering:
> > > > > > > > If I need to do remote un-/deployment from within client
> > > > > > applications,
> > > > > > > > is there already some existing API for doing that?
Perhaps
> > an
> > > > > > Endpoint
> > > > > > > > accepting service assemblies? If not, would some
> > Java-wrapper
> > > > around
> > > > > > the
> > > > > > > > aforementioned Ant tasks be a viable alternative?
> > > > > > > >
> > > > > > > > Thanks in advance,
> > > > > > > > Ciao,
> > > > > > > > Philipp
> > > > > > > >
> > > > > > > > This e-mail may contain confidential or privileged
> > information.
> > > > Any
> > > > > > > > unauthorised
> > > > > > > > copying, use or distribution of this information is
strictly
> > > > > > prohibited.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Cheers,
> > > > > > > Guillaume Nodet
> > > > > > > ------------------------
> > > > > > > Architect, LogicBlaze (http://www.logicblaze.com/)
> > > > > > > Blog: http://gnodet.blogspot.com/
> > > > > >
> > > > > > This e-mail may contain confidential or privileged
information.
> > Any
> > > > > > unauthorised
> > > > > > copying, use or distribution of this information is strictly
> > > > prohibited.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers,
> > > > > Guillaume Nodet
> > > > > ------------------------
> > > > > Architect, LogicBlaze (http://www.logicblaze.com/)
> > > > > Blog: http://gnodet.blogspot.com/
> > > >
> > > > This e-mail may contain confidential or privileged information.
Any
> > > > unauthorised
> > > > copying, use or distribution of this information is strictly
> > prohibited.
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Architect, LogicBlaze (http://www.logicblaze.com/)
> > > Blog: http://gnodet.blogspot.com/
> >
> > This e-mail may contain confidential or privileged information. Any
> > unauthorised
> > copying, use or distribution of this information is strictly
prohibited.
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
This e-mail may contain confidential or privileged information. Any unauthorised
copying, use or distribution of this information is strictly prohibited.
Re: Remote deployment of service assemblies
Posted by Guillaume Nodet <gn...@gmail.com>.
See http://issues.apache.org/activemq/browse/SM-858
which has been fixed a few weeks ago in trunk.
On 5/17/07, Rossmanith, Philipp <ph...@t-systems.es> wrote:
>
>
> Hi,
>
> After quite a break, I am back with the issue relating to this thread.
> What I did was creating a jsr-181 WSDL first service, for which I set a
> ComponentContext *). The setup is different from what had been outlined
> earlier, as I am creating a service assembly ZIP based on parameters I
> receive.
>
> My idea was to obtain a DeliveryChannelImpl from the ComponentContext
> and to then follow the steps Guillaume has pointed out below.
>
> However, the ComponentContext that is being set by SM is an
> EndpointComponentContext which doesn't give me access to this
> information.
>
> Any hints of how I can get hold of the JBIContainer or its
> AdminCommandsServiceMBean?
>
> Thanks in advance,
> Ciao,
> Philipp
>
> *) http://incubator.apache.org/servicemix/servicemix-jsr181.html
> **) For the moment, I am creating a service assembly zip file for WSN
> subscriptions once the service gets invoked. Parameters are the
> wsa:address, the topic and an identifier.
>
> > -----Mensaje original-----
> > De: Guillaume Nodet [mailto:gnodet@gmail.com]
> > Enviado el: martes, 20 de marzo de 2007 11:21
> > Para: servicemix-dev@geronimo.apache.org
> > Asunto: Re: Remote deployment of service assemblies
> >
> > On 3/20/07, Rossmanith, Philipp <ph...@t-systems.es>
> wrote:
> > >
> > >
> > > Hi,
> > >
> > > > Once you have the JBIContainer, just retrieve the needed
> interface:
> > > > JBIContainer container = dci.getContainer();
> > > > AdminCommandsServiceMBean admin =
> > > container.getAdminCommandsService();
> > > >
> > > > Then, you can use it to deploy / undeploy, manage life cycle, etc
> ..
> > > > admin.installComponent()
> > > > admin.startComponent()
> > > > admin.listServiceAssemblies() ...
> > > Ok, that is quite a bit cleaner...
> > >
> > > > all the administrative tasks are available from this interface, so
> I
> > > guess
> > > > the WSDL
> > > > should be quite easy to write. On the implementation side, one
> way is
> > > to
> > > > use
> > > > jaxb2 (not the full jsr181 though) as done in the WS-Notification
> > > > component.
> > > > See org.apache.servicemix.wsn.component.WSNEndpoint class.
> > > What I was thinking about was a WSDL wrapper around the
> > > AdminCommandsServiceMBean methods.
> > >
> > > I'm currently investigating the WSN component to use it for
> > > notifications based on message content (see
> > >
> http://www.nabble.com/how-to-implement-runtime-notifications-based-on-Me
> > > ssageExchange--content-tf3409844s12049.html), but I must say I'm
> afraid
> > > I don't really understand your idea (which may be due to my limited
> > > experience with jaxb2).
> > >
> > > It seems to me that the wsn component WSNEndpoint uses the
> annotations
> > > done in the org.apache.servicemix.wsn.AbstractEndpoint hierarchy (an
> > > object of this class is passed in as "pojo" in the constructor) to
> > > obtain a class object "endpointInterface" which is then used to get
> hold
> > > of the methods published in that interface. Jaxb2 seems to be used
> to
> > > unmarshal incoming normalized message content and to marshal it to
> > > outgoing exchanges (method: process).
> > >
> > > However, if I'm ""only"" writing a provider service and not a
> > > full-fledged component, what would be the advantages of the approach
> > > taken in WSNEndpoint?
> > >
> > > Or am I misinterpreting, and you're using jaxb2 for creating a
> jsr181
> > > code skeleton based on a previously generated WSDL?
> >
> >
> > Yeah, that's the point.
> > The WSNEndpoint is used to invoke an annotated POJO generated
> > from the WSDL like AbstractNotificationBroker.
> > The AbstractNotificationBroker#init method calls register, which
> > ultimately
> > creates a WSNEndpoint with the AbstractNotificationBroker class as the
> > pojo.
> >
> > So, once the WSDL is written, you can use wsgen to generate the
> interfaces
> > and messages, create your own POJO implementation and wrap it with
> > the WSNEndpoint. (It makes me think that this class may be put in
> > servicemix-common).
> >
> > But this is only one way to do that. Feel free to use your own if you
> > prefer.
> >
> > The last question is how do we package that. I'm thinking about
> > a SE, but without any support for deployments of SU,
> > I guess another way could be to leverage the JSR181 component and
> > just write a SU for it (and another for the http BC i guess).
> > The last way would be to configure it directly on the JBI container
> > without any JBI packaging ...
> > Need to think about pros / cons ...
> >
> > > .. and discussions about servicemix developement should take place
> on
> > > the
> > > > dev
> > > > list ... ;-)
> > > Done :-)
> >
> >
> > Thanks in advance,
> > > Ciao,
> > > Philipp
> > >
> > > > -----Mensaje original-----
> > > > De: Guillaume Nodet [mailto:gnodet@gmail.com]
> > > > Enviado el: lunes, 19 de marzo de 2007 16:56
> > > > Para: servicemix-users@geronimo.apache.org
> > > > Asunto: Re: Remote deployment of service assemblies
> > > > Importancia: Baja
> > > >
> > > > On 3/19/07, Rossmanith, Philipp <ph...@t-systems.es>
> > > wrote:
> > > > >
> > > > >
> > > > > > Currently, remote deployment is not supported by the ant
> tasks.
> > > > > > The only way to do currently that is to start a servicemix
> console
> > > > > > on the same server, because the console accepts uploads and
> will
> > > > > > be able to point the container to a local file.
> > > > > >
> > > > > > The only way using JMX would be to add a method accepting a
> byte[]
> > > > > > parameter which would be the content of the JBI artifact to
> > > deploy, or
> > > > > > creating an management endpoint on the JBI bus (using an
> > > attachment
> > > > > > for the JBI archetype). Not sure what's the best way.
> > > > > I was thinking about this alternative, as well. There could be a
> > > > > provider service that accepts calls having an SA attachment. It
> > > could
> > > > > then obtain this attachment and physically place it in the
> > > deployment
> > > > > dir.
> > > >
> > > >
> > > > Using the hot deployer is imo not the best solution.
> > > > We should use the AdminCommandsService instead (see below)
> > > >
> > > > In that way, one could use the same access control mechanism as
> for
> > > the
> > > > > rest of the service invocations. Another advantage would be that
> > > through
> > > > > the different binding components, the functionality would be
> > > available
> > > > > in more than just Java.
> > > >
> > > >
> > > > Yeah, agreed. We just need to define a clean WSDL for it.
> > > >
> > > > However, I'd need to access some JBIContainer properties, such as
> the
> > > > > deployment directory. I assume that the best way to obtain
> internals
> > > > > about the JBI container would be to use the client API
> > > > > (http://incubator.apache.org/servicemix/client-api.html).
> > > > >
> > > > > I could then use the following code:
> > > > > >>
> > > > > ...
> > > > > DeliveryChannelImpl dci = (DeliveryChannelImpl)
> > > > > defaultSMClientInstance.getDeliveryChannel();
> > > > > JBIContainer container = dci.getContainer();
> > > > > ...
> > > > > String deploymentDirPath = container.getDeploymentDirPath();
> > > > > ...
> > > > > <<
> > > > >
> > > > > However, this hack seems quite (if not: too) dirty. Is there a
> more
> > > > > elegant solution?
> > > >
> > > >
> > > >
> > > > Once you have the JBIContainer, just retrieve the needed
> interface:
> > > > JBIContainer container = dci.getContainer();
> > > > AdminCommandsServiceMBean admin =
> > > container.getAdminCommandsService();
> > > >
> > > > Then, you can use it to deploy / undeploy, manage life cycle, etc
> ..
> > > > admin.installComponent()
> > > > admin.startComponent()
> > > > admin.listServiceAssemblies() ...
> > > >
> > > > all the administrative tasks are available from this interface, so
> I
> > > guess
> > > > the WSDL
> > > > should be quite easy to write. On the implementation side, one
> way is
> > > to
> > > > use
> > > > jaxb2 (not the full jsr181 though) as done in the WS-Notification
> > > > component.
> > > > See org.apache.servicemix.wsn.component.WSNEndpoint class.
> > > >
> > > > .. and discussions about servicemix developement should take place
> on
> > > the
> > > > dev
> > > > list ... ;-)
> > > >
> > > > Thanks in advance,
> > > > > Ciao,
> > > > > Philipp
> > > > >
> > > > > > -----Mensaje original-----
> > > > > > De: Guillaume Nodet [mailto:gnodet@gmail.com]
> > > > > > Enviado el: lunes, 19 de marzo de 2007 16:01
> > > > > > Para: servicemix-users@geronimo.apache.org
> > > > > > Asunto: Re: Remote deployment of service assemblies
> > > > > > Importancia: Baja
> > > > > >
> > > > > > Currently, remote deployment is not supported by the ant
> tasks.
> > > > > > The only way to do currently that is to start a servicemix
> console
> > > > > > on the same server, because the console accepts uploads and
> will
> > > > > > be able to point the container to a local file.
> > > > > >
> > > > > > The only way using JMX would be to add a method accepting a
> byte[]
> > > > > > parameter which would be the content of the JBI artifact to
> > > deploy, or
> > > > > > creating an management endpoint on the JBI bus (using an
> > > attachment
> > > > > > for the JBI archetype). Not sure what's the best way.
> > > > > >
> > > > > > On 3/19/07, Rossmanith, Philipp
> <ph...@t-systems.es>
> > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > In our project, we have several client applications that
> need to
> > > > > deploy
> > > > > > > and undeploy service assemblies at runtime. The majority of
> them
> > > are
> > > > > > > written in Java, others not.
> > > > > > >
> > > > > > > It seems that remote administration is something that would
> best
> > > be
> > > > > > > handled by the administration Ant tasks.
> > > > > > >
> > > > > > > Ant tasks can be called from Java code:
> > > > > > > http://ant.apache.org/manual/antexternal.html
> > > > > > >
> > > > > > > Now I was wondering:
> > > > > > > If I need to do remote un-/deployment from within client
> > > > > applications,
> > > > > > > is there already some existing API for doing that? Perhaps
> an
> > > > > Endpoint
> > > > > > > accepting service assemblies? If not, would some
> Java-wrapper
> > > around
> > > > > the
> > > > > > > aforementioned Ant tasks be a viable alternative?
> > > > > > >
> > > > > > > Thanks in advance,
> > > > > > > Ciao,
> > > > > > > Philipp
> > > > > > >
> > > > > > > This e-mail may contain confidential or privileged
> information.
> > > Any
> > > > > > > unauthorised
> > > > > > > copying, use or distribution of this information is strictly
> > > > > prohibited.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > > Guillaume Nodet
> > > > > > ------------------------
> > > > > > Architect, LogicBlaze (http://www.logicblaze.com/)
> > > > > > Blog: http://gnodet.blogspot.com/
> > > > >
> > > > > This e-mail may contain confidential or privileged information.
> Any
> > > > > unauthorised
> > > > > copying, use or distribution of this information is strictly
> > > prohibited.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > > ------------------------
> > > > Architect, LogicBlaze (http://www.logicblaze.com/)
> > > > Blog: http://gnodet.blogspot.com/
> > >
> > > This e-mail may contain confidential or privileged information. Any
> > > unauthorised
> > > copying, use or distribution of this information is strictly
> prohibited.
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Architect, LogicBlaze (http://www.logicblaze.com/)
> > Blog: http://gnodet.blogspot.com/
>
> This e-mail may contain confidential or privileged information. Any
> unauthorised
> copying, use or distribution of this information is strictly prohibited.
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/