You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Philip Dodds <ph...@gmail.com> on 2006/01/17 20:11:47 UTC
JBI Deployer
We've been working on a re-usable deployment plugin for eclipse to try and
simplify the process of create components and actually making them
re-usable. The basic idea is fairly simple, when you build you JBI
component, whether it be a binding component or a service engine you
include a components.xml in the META-INF directory, which holds information
about your component, and example of which is below:
<components>
<component type="binding-component">
<componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid>
<name>Groovy Script</name>
<description>
A component that can be deployed with an embedded Groovy Script
</description>
<assets>
<embeddedArtifact name="script.groovy" extension="groovy"
description="Your Groovy Script" />
<parameter name="exampleparameter" defaultValue="haha"
description="Example parameter"/>
<connection default="true" name="defaultDestination"
description="Default destination" mep="robustInOnly" />
</assets>
</component>
In essence the idea of your components.xml is to describe your components,
which can be either binding-components or service-engine, you can also
define embedded artifacts which are files you expect to be bundles with
either your service engine or binding-component, there is also space for
parameters and also connections to other services. The idea behind this is
to express your requirements for your component so that someone knows what
they need to provide to get your working, the idea here is to make your
component re-usable without needing the source code.
Then basically we have two projects, one which is the descriptors for this
components.xml and also a file called assets.xml and the second is an
eclipse plugin that you can install and then register your components with,
once you have the eclipse plugin installed in your eclipse you basically can
goto preferences in eclipse and add all the packaged JBI components,
basically those JBI components with a jbi.xml that are your usual stuff but
also with a components.xml in there. Once you have registered them you can
create a project and add a file with the extension .jbi, this will open the
JBI deployer which is basically just a GEF diagramming component, however
you will see you components (as registered from your components.xml) in the
pallette, if you drop one on the canvas you will be able to configure the
settings (those also defined in the components.xml) and therefore configure
a re-usable JBI component. If you component is a service engine you will
see component and be able to press the + button to create service units
inside, note that in this case you can gather parameters at a service unit
by added parameters etc at the service unit level ie:
<component type="service-engine">
<componentUuid>658c0460-7ee0-11da-ba83-0002a5d5c51c</componentUuid>
<name>Translator</name>
<description>
Unity's transformation service engine
</description>
<serviceUnit>
<assets>
<embeddedArtifact name="translator.xml" extension="trslr"
description="Translator Configuration" />
<parameter name="exampleparameter" defaultValue="haha"
description="Example parameter"/>
<connection default="true" name="defaultDestination"
description="Default destination"
mep="robustInOnly" />
</assets>
</serviceUnit>
</component>
</components>
Once you have set up your digram as you want it you can right click on a
component or service assembly and choose deploy, this will create the
component zips by basically exploding the base jar (which the components.xml)
and creating a new component injecting both the embeddedArtifacts and also
the assets (which are the parameters gathered from the deployment editor),
therefore you would have META-INF/stored-assets.xml in either your
binding-component or your service unit ie.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<storedAssets> <artifactReference><name>script.groovy</name><path>
whizbang.groovy</path></artifactReference><resourceReference><name>defaultDestination</name><resource
xmlns:ns3="http://openuri.org">ns3:newService2</resource></resourceReference><serviceName
xmlns:ns3="http://openuri.org">ns3:newService</serviceName></storedAssets>
In the descriptor package with then supply a simple StoredAssetFactory you
can give either your service unit deploy path to or your component context
to get your assets back.
The basic idea here is to make the packaging of a JBI component or re-use
and also the deployment of complex patterns easier with a graphical
environment and a mechanism for exposing your code and requesting the
artifacts etc you want.
We (Unity Systems) have been working on this for the past couple of months
and believe that the ServiceMix project would benefit from this style of
deployment as it would enable easier configuration and deployment. There
are a couple of downsides first is it was written for Java 5 and the second
is a dependency on JAXB2.
If the team think this is a good idea or have comments we can place a cut of
the code somewhere for review or we can make it a tooling project and
examine maybe how we could document the lw-container to make it a good basis
to writing a component and passing it parameters, also we might want to
see if some of the service-components could be modified to be able to use
the stored assets if available.
All comments and thoughts are welcome :)
Cheers
P
Re: JBI Deployer
Posted by Philip Dodds <ph...@gmail.com>.
Hossam,
The deployer currently supports generating service assemblies and the
zipping up of the SU artifacts, also the generation of the jbi.xml for the
service assembly so you can certainly get the reuse. As for the service
units they don't appear on the palette but once you drop an SA onto the
canvas you can add instances of SU to it.
Certainly sounds like some good ideas, once the base is in you can see
where we got and we can look at what needs doing.. one of the things I
would like to see is better Eclipse support in general for JBI and
ServiceMix such as starting servers under Eclipse and JBI projects.
We should have the code in SVN tomorrow, because originally it was written
internally I wanted to get all the renaming and licensing stuff sorted out
before checking in.
Cheers
P
On 1/18/06, Hossam Karim <hr...@gmail.com> wrote:
>
> When I was reading the specification, I was really annoyed by the fact
> that
> a Service Unit would require a deployment descriptor by itself regardless
> of
> the container Service Assembly. After I started practicing JBI I realized
> the great reusability this requirement offers. The expert group really had
> tooling in mind.
> When you use the same deployment artifact at design time, you would
> perfectly allow other tools, if any, to do their job. For example, the
> method I mentioned earlier, that my team is currently using, would allow
> us
> to use both approaches back and forth. I attached the profile and a sample
> implementation, it might be helpful.
>
> I have a few other suggestions:
> - You mentioned in your first post that one needs to register a component
> first to be visible on the palette, can you enable dynamic lookup of
> existing JAR or ZIP files. And as you said, you would read or inject your
> configurations into the descriptor.
> - Should I be able to register or look up a Service Assembly or a Service
> Unit and see it on the palette as well?? Ok, what about a Shared Library?
> - May be in the future you can directly or indirectly support UML 2.0 XMI
> export and import (quite a job) from Eclipse. Tools like Borland Together
> and IBM RSA will understand this. Am I going too far?
>
> I really hope I would be able to checkout and play with this tool soon.
>
> Thanks,
> Hossam Karim
>
> -----Original Message-----
> From: Philip Dodds [mailto:philip.dodds@gmail.com]
> Sent: Wednesday, January 18, 2006 6:01 PM
> To: servicemix-dev@geronimo.apache.org
> Subject: Re: JBI Deployer
>
> Hossam,
>
> I've been thinking and we can probably switch it so that in the event of
> us
> not finding the components.xml we can switch it back to the jbi.xml and
> see
> if there are any assets in place there, in this way we can support
> multiple
> components and the more natural single component approach, I'll try and
> get
> that in place in the next week :)
>
> Cheers
>
> P
>
> On 1/17/06, Philip Dodds <ph...@gmail.com> wrote:
> >
> > Currently there are three projects...not sure quite where to put them,
> > basically they are:
> >
> > servicemix-packaging-descriptors - The packaging descriptors and helper
> > factories
> > servicemix-packaging-eclipse-plugin - The Eclipse plugin itself
> >
> > maven2-eclipse-plugin-plugin - Horribly named but does what it says,
> > basically a Maven2 plugin that can be used to generate the MANFEST.MFfor
> > Eclipse 3.0 based on the pom.xml
> >
> > On the beer note I'm still working out if I'll be in Aylesbury in Feb so
> I
> > might be able to make claim to a few :)
> >
> > Cheers
> >
> > P
> >
> > On 1/17/06, James Strachan <ja...@gmail.com> wrote:
> > >
> > >
> > > On 17 Jan 2006, at 11:11, Philip Dodds wrote:
> > > > We've been working on a re-usable deployment plugin for eclipse to
> > > > try and simplify the process of create components and actually
> > > > making them re-usable. The basic idea is fairly simple, when you
> > > > build you JBI component, whether it be a binding component or a
> > > > service engine you include a components.xml in the META-INF
> > > > directory, which holds information about your component, and
> > > > example of which is below:
> > > >
> > > > <components>
> > > > <component type="binding-component">
> > > >
> > > > <componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid>
> > > > <name>Groovy Script</name>
> > > > <description>
> > > > A component that can be deployed with an embedded Groovy Script
> > > > </description>
> > > > <assets>
> > > > <embeddedArtifact name="script.groovy " extension="groovy"
> > > > description="Your Groovy Script" />
> > > > <parameter name="exampleparameter" defaultValue="haha"
> > > >
> > > > description="Example parameter"/>
> > > > <connection default="true" name="defaultDestination"
> > > >
> > > > description="Default destination" mep="robustInOnly" />
> > > > </assets>
> > > > </component>
> > > >
> > > > In essence the idea of your components.xml is to describe your
> > > > components, which can be either binding-components or service-
> > > > engine, you can also define embedded artifacts which are files you
> > > > expect to be bundles with either your service engine or binding-
> > > > component, there is also space for parameters and also connections
> > > > to other services. The idea behind this is to express your
> > > > requirements for your component so that someone knows what they
> > > > need to provide to get your working, the idea here is to make your
> > > > component re-usable without needing the source code.
> > > >
> > > > Then basically we have two projects, one which is the descriptors
> > > > for this components.xml and also a file called assets.xml and the
> > > > second is an eclipse plugin that you can install and then register
> > > > your components with, once you have the eclipse plugin installed
> > > > in your eclipse you basically can goto preferences in eclipse and
> > > > add all the packaged JBI components, basically those JBI
> > > > components with a jbi.xml that are your usual stuff but also with a
> > > > components.xml in there. Once you have registered them you can
> > > > create a project and add a file with the extension .jbi, this will
> > > > open the JBI deployer which is basically just a GEF diagramming
> > > > component, however you will see you components (as registered from
> > > > your components.xml) in the pallette, if you drop one on the canvas
> > > > you will be able to configure the settings (those also defined in
> > > > the components.xml) and therefore configure a re-usable JBI
> > > > component. If you component is a service engine you will see
> > > > component and be able to press the + button to create service units
> > > > inside, note that in this case you can gather parameters at a
> > > > service unit by added parameters etc at the service unit level ie:
> > > >
> > > > <component type="service-engine">
> > > > <componentUuid>658c0460-7ee0-11da-ba83-0002a5d5c51c</
> > > > componentUuid>
> > > > <name>Translator</name>
> > > > <description>
> > > > Unity's transformation service engine
> > > > </description>
> > > > <serviceUnit>
> > > > <assets>
> > > > <embeddedArtifact name=" translator.xml"
> extension="trslr"
> > > > description="Translator Configuration" />
> > > > <parameter name="exampleparameter" defaultValue="haha"
> > > > description="Example parameter"/>
> > > > <connection default="true" name="defaultDestination"
> > > > description="Default destination"
> > > > mep="robustInOnly" />
> > > > </assets>
> > > > </serviceUnit>
> > > > </component>
> > > > </components>
> > > >
> > > > Once you have set up your digram as you want it you can right click
> > > > on a component or service assembly and choose deploy, this will
> > > > create the component zips by basically exploding the base jar
> > > > (which the components.xml) and creating a new component injecting
> > > > both the embeddedArtifacts and also the assets (which are the
> > > > parameters gathered from the deployment editor), therefore you
> > > > would have META-INF/stored-assets.xml in either your binding-
> > > > component or your service unit ie.
> > > >
> > > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> > > > <storedAssets> <artifactReference><name>script.groovy</
> > > > name><path>whizbang.groovy</path></
> > > > artifactReference><resourceReference><name>defaultDestination</
> > > > name><resource xmlns:ns3=" http://openuri.org">ns3:newService2</
> > > > resource></resourceReference><serviceName xmlns:ns3="http://
> > > > openuri.org">ns3:newService</serviceName></storedAssets>
> > > >
> > > > In the descriptor package with then supply a simple
> > > > StoredAssetFactory you can give either your service unit deploy
> > > > path to or your component context to get your assets back.
> > > >
> > > > The basic idea here is to make the packaging of a JBI component or
> > > > re-use and also the deployment of complex patterns easier with a
> > > > graphical environment and a mechanism for exposing your code and
> > > > requesting the artifacts etc you want.
> > > >
> > > > We (Unity Systems) have been working on this for the past couple of
> > > > months and believe that the ServiceMix project would benefit from
> > > > this style of deployment as it would enable easier configuration
> > > > and deployment. There are a couple of downsides first is it was
> > > > written for Java 5 and the second is a dependency on JAXB2.
> > >
> > > Awesome!
> > >
> > > FWIW thanks to the retrotranslator project - and the maven2 plugin -
> > > we can actually generate 1.4 jars for Java 5 code and JAXB2 HEAD
> > > works on it!
> > > http://retrotranslator.sourceforge.net/
> > >
> > > Many thanks to Kohsuke from the JAXB team for helping fix JAXB/JAXP
> > > and Hiram for the m2 retrotranslator plugin (with lots of help from
> > > Brett) and mostly for Taras for doing all the hard work of
> > > translating 1.5 code into working 1.4 bytecode (including generics,
> > > annotations, java-util-concurrent etc).
> > >
> > > So depending on Java 5 and JAXB2 is fine; we can just generate 1.4
> > > versions where we need to. It does mean that the build itself depends
> > > on Java 5 but thats no big deal.
> > >
> > >
> > > > If the team think this is a good idea or have comments we can place
> > > > a cut of the code somewhere for review or we can make it a tooling
> > > > project and examine maybe how we could document the lw-container to
> > > > make it a good basis to writing a component and passing it
> > > > parameters, also we might want to see if some of the service-
> > > > components could be modified to be able to use the stored assets if
> > > > available.
> > > >
> > > > All comments and thoughts are welcome :)
> > >
> > > Sounds awesome - bring it on Philip! :)
> > >
> > > By all means just check the code into the Apache ServiceMix repo if
> > > you want. If you didn't write all the code we'll need CLAs to be on
> > > file at Apache.
> > >
> > > I owe you a few more beers for this :)
> > >
> > > James
> > > -------
> > > http://radio.weblogs.com/0112098/
> > >
> > >
> > >
> >
>
>
RE: JBI Deployer
Posted by Hossam Karim <hr...@gmail.com>.
When I was reading the specification, I was really annoyed by the fact that
a Service Unit would require a deployment descriptor by itself regardless of
the container Service Assembly. After I started practicing JBI I realized
the great reusability this requirement offers. The expert group really had
tooling in mind.
When you use the same deployment artifact at design time, you would
perfectly allow other tools, if any, to do their job. For example, the
method I mentioned earlier, that my team is currently using, would allow us
to use both approaches back and forth. I attached the profile and a sample
implementation, it might be helpful.
I have a few other suggestions:
- You mentioned in your first post that one needs to register a component
first to be visible on the palette, can you enable dynamic lookup of
existing JAR or ZIP files. And as you said, you would read or inject your
configurations into the descriptor.
- Should I be able to register or look up a Service Assembly or a Service
Unit and see it on the palette as well?? Ok, what about a Shared Library?
- May be in the future you can directly or indirectly support UML 2.0 XMI
export and import (quite a job) from Eclipse. Tools like Borland Together
and IBM RSA will understand this. Am I going too far?
I really hope I would be able to checkout and play with this tool soon.
Thanks,
Hossam Karim
-----Original Message-----
From: Philip Dodds [mailto:philip.dodds@gmail.com]
Sent: Wednesday, January 18, 2006 6:01 PM
To: servicemix-dev@geronimo.apache.org
Subject: Re: JBI Deployer
Hossam,
I've been thinking and we can probably switch it so that in the event of us
not finding the components.xml we can switch it back to the jbi.xml and see
if there are any assets in place there, in this way we can support multiple
components and the more natural single component approach, I'll try and get
that in place in the next week :)
Cheers
P
On 1/17/06, Philip Dodds <ph...@gmail.com> wrote:
>
> Currently there are three projects...not sure quite where to put them,
> basically they are:
>
> servicemix-packaging-descriptors - The packaging descriptors and helper
> factories
> servicemix-packaging-eclipse-plugin - The Eclipse plugin itself
>
> maven2-eclipse-plugin-plugin - Horribly named but does what it says,
> basically a Maven2 plugin that can be used to generate the MANFEST.MF for
> Eclipse 3.0 based on the pom.xml
>
> On the beer note I'm still working out if I'll be in Aylesbury in Feb so I
> might be able to make claim to a few :)
>
> Cheers
>
> P
>
> On 1/17/06, James Strachan <ja...@gmail.com> wrote:
> >
> >
> > On 17 Jan 2006, at 11:11, Philip Dodds wrote:
> > > We've been working on a re-usable deployment plugin for eclipse to
> > > try and simplify the process of create components and actually
> > > making them re-usable. The basic idea is fairly simple, when you
> > > build you JBI component, whether it be a binding component or a
> > > service engine you include a components.xml in the META-INF
> > > directory, which holds information about your component, and
> > > example of which is below:
> > >
> > > <components>
> > > <component type="binding-component">
> > >
> > > <componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid>
> > > <name>Groovy Script</name>
> > > <description>
> > > A component that can be deployed with an embedded Groovy Script
> > > </description>
> > > <assets>
> > > <embeddedArtifact name="script.groovy " extension="groovy"
> > > description="Your Groovy Script" />
> > > <parameter name="exampleparameter" defaultValue="haha"
> > >
> > > description="Example parameter"/>
> > > <connection default="true" name="defaultDestination"
> > >
> > > description="Default destination" mep="robustInOnly" />
> > > </assets>
> > > </component>
> > >
> > > In essence the idea of your components.xml is to describe your
> > > components, which can be either binding-components or service-
> > > engine, you can also define embedded artifacts which are files you
> > > expect to be bundles with either your service engine or binding-
> > > component, there is also space for parameters and also connections
> > > to other services. The idea behind this is to express your
> > > requirements for your component so that someone knows what they
> > > need to provide to get your working, the idea here is to make your
> > > component re-usable without needing the source code.
> > >
> > > Then basically we have two projects, one which is the descriptors
> > > for this components.xml and also a file called assets.xml and the
> > > second is an eclipse plugin that you can install and then register
> > > your components with, once you have the eclipse plugin installed
> > > in your eclipse you basically can goto preferences in eclipse and
> > > add all the packaged JBI components, basically those JBI
> > > components with a jbi.xml that are your usual stuff but also with a
> > > components.xml in there. Once you have registered them you can
> > > create a project and add a file with the extension .jbi, this will
> > > open the JBI deployer which is basically just a GEF diagramming
> > > component, however you will see you components (as registered from
> > > your components.xml) in the pallette, if you drop one on the canvas
> > > you will be able to configure the settings (those also defined in
> > > the components.xml) and therefore configure a re-usable JBI
> > > component. If you component is a service engine you will see
> > > component and be able to press the + button to create service units
> > > inside, note that in this case you can gather parameters at a
> > > service unit by added parameters etc at the service unit level ie:
> > >
> > > <component type="service-engine">
> > > <componentUuid>658c0460-7ee0-11da-ba83-0002a5d5c51c</
> > > componentUuid>
> > > <name>Translator</name>
> > > <description>
> > > Unity's transformation service engine
> > > </description>
> > > <serviceUnit>
> > > <assets>
> > > <embeddedArtifact name=" translator.xml" extension="trslr"
> > > description="Translator Configuration" />
> > > <parameter name="exampleparameter" defaultValue="haha"
> > > description="Example parameter"/>
> > > <connection default="true" name="defaultDestination"
> > > description="Default destination"
> > > mep="robustInOnly" />
> > > </assets>
> > > </serviceUnit>
> > > </component>
> > > </components>
> > >
> > > Once you have set up your digram as you want it you can right click
> > > on a component or service assembly and choose deploy, this will
> > > create the component zips by basically exploding the base jar
> > > (which the components.xml) and creating a new component injecting
> > > both the embeddedArtifacts and also the assets (which are the
> > > parameters gathered from the deployment editor), therefore you
> > > would have META-INF/stored-assets.xml in either your binding-
> > > component or your service unit ie.
> > >
> > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> > > <storedAssets> <artifactReference><name>script.groovy</
> > > name><path>whizbang.groovy</path></
> > > artifactReference><resourceReference><name>defaultDestination</
> > > name><resource xmlns:ns3=" http://openuri.org">ns3:newService2</
> > > resource></resourceReference><serviceName xmlns:ns3="http://
> > > openuri.org">ns3:newService</serviceName></storedAssets>
> > >
> > > In the descriptor package with then supply a simple
> > > StoredAssetFactory you can give either your service unit deploy
> > > path to or your component context to get your assets back.
> > >
> > > The basic idea here is to make the packaging of a JBI component or
> > > re-use and also the deployment of complex patterns easier with a
> > > graphical environment and a mechanism for exposing your code and
> > > requesting the artifacts etc you want.
> > >
> > > We (Unity Systems) have been working on this for the past couple of
> > > months and believe that the ServiceMix project would benefit from
> > > this style of deployment as it would enable easier configuration
> > > and deployment. There are a couple of downsides first is it was
> > > written for Java 5 and the second is a dependency on JAXB2.
> >
> > Awesome!
> >
> > FWIW thanks to the retrotranslator project - and the maven2 plugin -
> > we can actually generate 1.4 jars for Java 5 code and JAXB2 HEAD
> > works on it!
> > http://retrotranslator.sourceforge.net/
> >
> > Many thanks to Kohsuke from the JAXB team for helping fix JAXB/JAXP
> > and Hiram for the m2 retrotranslator plugin (with lots of help from
> > Brett) and mostly for Taras for doing all the hard work of
> > translating 1.5 code into working 1.4 bytecode (including generics,
> > annotations, java-util-concurrent etc).
> >
> > So depending on Java 5 and JAXB2 is fine; we can just generate 1.4
> > versions where we need to. It does mean that the build itself depends
> > on Java 5 but thats no big deal.
> >
> >
> > > If the team think this is a good idea or have comments we can place
> > > a cut of the code somewhere for review or we can make it a tooling
> > > project and examine maybe how we could document the lw-container to
> > > make it a good basis to writing a component and passing it
> > > parameters, also we might want to see if some of the service-
> > > components could be modified to be able to use the stored assets if
> > > available.
> > >
> > > All comments and thoughts are welcome :)
> >
> > Sounds awesome - bring it on Philip! :)
> >
> > By all means just check the code into the Apache ServiceMix repo if
> > you want. If you didn't write all the code we'll need CLAs to be on
> > file at Apache.
> >
> > I owe you a few more beers for this :)
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
> >
> >
>
Re: JBI Deployer
Posted by Philip Dodds <ph...@gmail.com>.
Hossam,
I've been thinking and we can probably switch it so that in the event of us
not finding the components.xml we can switch it back to the jbi.xml and see
if there are any assets in place there, in this way we can support multiple
components and the more natural single component approach, I'll try and get
that in place in the next week :)
Cheers
P
On 1/17/06, Philip Dodds <ph...@gmail.com> wrote:
>
> Currently there are three projects...not sure quite where to put them,
> basically they are:
>
> servicemix-packaging-descriptors - The packaging descriptors and helper
> factories
> servicemix-packaging-eclipse-plugin - The Eclipse plugin itself
>
> maven2-eclipse-plugin-plugin - Horribly named but does what it says,
> basically a Maven2 plugin that can be used to generate the MANFEST.MF for
> Eclipse 3.0 based on the pom.xml
>
> On the beer note I'm still working out if I'll be in Aylesbury in Feb so I
> might be able to make claim to a few :)
>
> Cheers
>
> P
>
> On 1/17/06, James Strachan <ja...@gmail.com> wrote:
> >
> >
> > On 17 Jan 2006, at 11:11, Philip Dodds wrote:
> > > We've been working on a re-usable deployment plugin for eclipse to
> > > try and simplify the process of create components and actually
> > > making them re-usable. The basic idea is fairly simple, when you
> > > build you JBI component, whether it be a binding component or a
> > > service engine you include a components.xml in the META-INF
> > > directory, which holds information about your component, and
> > > example of which is below:
> > >
> > > <components>
> > > <component type="binding-component">
> > >
> > > <componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid>
> > > <name>Groovy Script</name>
> > > <description>
> > > A component that can be deployed with an embedded Groovy Script
> > > </description>
> > > <assets>
> > > <embeddedArtifact name="script.groovy " extension="groovy"
> > > description="Your Groovy Script" />
> > > <parameter name="exampleparameter" defaultValue="haha"
> > >
> > > description="Example parameter"/>
> > > <connection default="true" name="defaultDestination"
> > >
> > > description="Default destination" mep="robustInOnly" />
> > > </assets>
> > > </component>
> > >
> > > In essence the idea of your components.xml is to describe your
> > > components, which can be either binding-components or service-
> > > engine, you can also define embedded artifacts which are files you
> > > expect to be bundles with either your service engine or binding-
> > > component, there is also space for parameters and also connections
> > > to other services. The idea behind this is to express your
> > > requirements for your component so that someone knows what they
> > > need to provide to get your working, the idea here is to make your
> > > component re-usable without needing the source code.
> > >
> > > Then basically we have two projects, one which is the descriptors
> > > for this components.xml and also a file called assets.xml and the
> > > second is an eclipse plugin that you can install and then register
> > > your components with, once you have the eclipse plugin installed
> > > in your eclipse you basically can goto preferences in eclipse and
> > > add all the packaged JBI components, basically those JBI
> > > components with a jbi.xml that are your usual stuff but also with a
> > > components.xml in there. Once you have registered them you can
> > > create a project and add a file with the extension .jbi, this will
> > > open the JBI deployer which is basically just a GEF diagramming
> > > component, however you will see you components (as registered from
> > > your components.xml) in the pallette, if you drop one on the canvas
> > > you will be able to configure the settings (those also defined in
> > > the components.xml) and therefore configure a re-usable JBI
> > > component. If you component is a service engine you will see
> > > component and be able to press the + button to create service units
> > > inside, note that in this case you can gather parameters at a
> > > service unit by added parameters etc at the service unit level ie:
> > >
> > > <component type="service-engine">
> > > <componentUuid>658c0460-7ee0-11da-ba83-0002a5d5c51c</
> > > componentUuid>
> > > <name>Translator</name>
> > > <description>
> > > Unity's transformation service engine
> > > </description>
> > > <serviceUnit>
> > > <assets>
> > > <embeddedArtifact name=" translator.xml" extension="trslr"
> > > description="Translator Configuration" />
> > > <parameter name="exampleparameter" defaultValue="haha"
> > > description="Example parameter"/>
> > > <connection default="true" name="defaultDestination"
> > > description="Default destination"
> > > mep="robustInOnly" />
> > > </assets>
> > > </serviceUnit>
> > > </component>
> > > </components>
> > >
> > > Once you have set up your digram as you want it you can right click
> > > on a component or service assembly and choose deploy, this will
> > > create the component zips by basically exploding the base jar
> > > (which the components.xml) and creating a new component injecting
> > > both the embeddedArtifacts and also the assets (which are the
> > > parameters gathered from the deployment editor), therefore you
> > > would have META-INF/stored-assets.xml in either your binding-
> > > component or your service unit ie.
> > >
> > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> > > <storedAssets> <artifactReference><name>script.groovy</
> > > name><path>whizbang.groovy</path></
> > > artifactReference><resourceReference><name>defaultDestination</
> > > name><resource xmlns:ns3=" http://openuri.org">ns3:newService2</
> > > resource></resourceReference><serviceName xmlns:ns3="http://
> > > openuri.org">ns3:newService</serviceName></storedAssets>
> > >
> > > In the descriptor package with then supply a simple
> > > StoredAssetFactory you can give either your service unit deploy
> > > path to or your component context to get your assets back.
> > >
> > > The basic idea here is to make the packaging of a JBI component or
> > > re-use and also the deployment of complex patterns easier with a
> > > graphical environment and a mechanism for exposing your code and
> > > requesting the artifacts etc you want.
> > >
> > > We (Unity Systems) have been working on this for the past couple of
> > > months and believe that the ServiceMix project would benefit from
> > > this style of deployment as it would enable easier configuration
> > > and deployment. There are a couple of downsides first is it was
> > > written for Java 5 and the second is a dependency on JAXB2.
> >
> > Awesome!
> >
> > FWIW thanks to the retrotranslator project - and the maven2 plugin -
> > we can actually generate 1.4 jars for Java 5 code and JAXB2 HEAD
> > works on it!
> > http://retrotranslator.sourceforge.net/
> >
> > Many thanks to Kohsuke from the JAXB team for helping fix JAXB/JAXP
> > and Hiram for the m2 retrotranslator plugin (with lots of help from
> > Brett) and mostly for Taras for doing all the hard work of
> > translating 1.5 code into working 1.4 bytecode (including generics,
> > annotations, java-util-concurrent etc).
> >
> > So depending on Java 5 and JAXB2 is fine; we can just generate 1.4
> > versions where we need to. It does mean that the build itself depends
> > on Java 5 but thats no big deal.
> >
> >
> > > If the team think this is a good idea or have comments we can place
> > > a cut of the code somewhere for review or we can make it a tooling
> > > project and examine maybe how we could document the lw-container to
> > > make it a good basis to writing a component and passing it
> > > parameters, also we might want to see if some of the service-
> > > components could be modified to be able to use the stored assets if
> > > available.
> > >
> > > All comments and thoughts are welcome :)
> >
> > Sounds awesome - bring it on Philip! :)
> >
> > By all means just check the code into the Apache ServiceMix repo if
> > you want. If you didn't write all the code we'll need CLAs to be on
> > file at Apache.
> >
> > I owe you a few more beers for this :)
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
> >
> >
>
Re: JBI Deployer
Posted by Philip Dodds <ph...@gmail.com>.
Currently there are three projects...not sure quite where to put them,
basically they are:
servicemix-packaging-descriptors - The packaging descriptors and helper
factories
servicemix-packaging-eclipse-plugin - The Eclipse plugin itself
maven2-eclipse-plugin-plugin - Horribly named but does what it says,
basically a Maven2 plugin that can be used to generate the MANFEST.MF for
Eclipse 3.0 based on the pom.xml
On the beer note I'm still working out if I'll be in Aylesbury in Feb so I
might be able to make claim to a few :)
Cheers
P
On 1/17/06, James Strachan <ja...@gmail.com> wrote:
>
>
> On 17 Jan 2006, at 11:11, Philip Dodds wrote:
> > We've been working on a re-usable deployment plugin for eclipse to
> > try and simplify the process of create components and actually
> > making them re-usable. The basic idea is fairly simple, when you
> > build you JBI component, whether it be a binding component or a
> > service engine you include a components.xml in the META-INF
> > directory, which holds information about your component, and
> > example of which is below:
> >
> > <components>
> > <component type="binding-component">
> >
> > <componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid>
> > <name>Groovy Script</name>
> > <description>
> > A component that can be deployed with an embedded Groovy Script
> > </description>
> > <assets>
> > <embeddedArtifact name="script.groovy" extension="groovy"
> > description="Your Groovy Script" />
> > <parameter name="exampleparameter" defaultValue="haha"
> >
> > description="Example parameter"/>
> > <connection default="true" name="defaultDestination"
> >
> > description="Default destination" mep="robustInOnly" />
> > </assets>
> > </component>
> >
> > In essence the idea of your components.xml is to describe your
> > components, which can be either binding-components or service-
> > engine, you can also define embedded artifacts which are files you
> > expect to be bundles with either your service engine or binding-
> > component, there is also space for parameters and also connections
> > to other services. The idea behind this is to express your
> > requirements for your component so that someone knows what they
> > need to provide to get your working, the idea here is to make your
> > component re-usable without needing the source code.
> >
> > Then basically we have two projects, one which is the descriptors
> > for this components.xml and also a file called assets.xml and the
> > second is an eclipse plugin that you can install and then register
> > your components with, once you have the eclipse plugin installed
> > in your eclipse you basically can goto preferences in eclipse and
> > add all the packaged JBI components, basically those JBI
> > components with a jbi.xml that are your usual stuff but also with a
> > components.xml in there. Once you have registered them you can
> > create a project and add a file with the extension .jbi, this will
> > open the JBI deployer which is basically just a GEF diagramming
> > component, however you will see you components (as registered from
> > your components.xml) in the pallette, if you drop one on the canvas
> > you will be able to configure the settings (those also defined in
> > the components.xml) and therefore configure a re-usable JBI
> > component. If you component is a service engine you will see
> > component and be able to press the + button to create service units
> > inside, note that in this case you can gather parameters at a
> > service unit by added parameters etc at the service unit level ie:
> >
> > <component type="service-engine">
> > <componentUuid>658c0460-7ee0-11da-ba83-0002a5d5c51c</
> > componentUuid>
> > <name>Translator</name>
> > <description>
> > Unity's transformation service engine
> > </description>
> > <serviceUnit>
> > <assets>
> > <embeddedArtifact name="translator.xml" extension="trslr"
> > description="Translator Configuration" />
> > <parameter name="exampleparameter" defaultValue="haha"
> > description="Example parameter"/>
> > <connection default="true" name="defaultDestination"
> > description="Default destination"
> > mep="robustInOnly" />
> > </assets>
> > </serviceUnit>
> > </component>
> > </components>
> >
> > Once you have set up your digram as you want it you can right click
> > on a component or service assembly and choose deploy, this will
> > create the component zips by basically exploding the base jar
> > (which the components.xml) and creating a new component injecting
> > both the embeddedArtifacts and also the assets (which are the
> > parameters gathered from the deployment editor), therefore you
> > would have META-INF/stored-assets.xml in either your binding-
> > component or your service unit ie.
> >
> > <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> > <storedAssets> <artifactReference><name>script.groovy</
> > name><path>whizbang.groovy</path></
> > artifactReference><resourceReference><name>defaultDestination</
> > name><resource xmlns:ns3=" http://openuri.org">ns3:newService2</
> > resource></resourceReference><serviceName xmlns:ns3="http://
> > openuri.org">ns3:newService</serviceName></storedAssets>
> >
> > In the descriptor package with then supply a simple
> > StoredAssetFactory you can give either your service unit deploy
> > path to or your component context to get your assets back.
> >
> > The basic idea here is to make the packaging of a JBI component or
> > re-use and also the deployment of complex patterns easier with a
> > graphical environment and a mechanism for exposing your code and
> > requesting the artifacts etc you want.
> >
> > We (Unity Systems) have been working on this for the past couple of
> > months and believe that the ServiceMix project would benefit from
> > this style of deployment as it would enable easier configuration
> > and deployment. There are a couple of downsides first is it was
> > written for Java 5 and the second is a dependency on JAXB2.
>
> Awesome!
>
> FWIW thanks to the retrotranslator project - and the maven2 plugin -
> we can actually generate 1.4 jars for Java 5 code and JAXB2 HEAD
> works on it!
> http://retrotranslator.sourceforge.net/
>
> Many thanks to Kohsuke from the JAXB team for helping fix JAXB/JAXP
> and Hiram for the m2 retrotranslator plugin (with lots of help from
> Brett) and mostly for Taras for doing all the hard work of
> translating 1.5 code into working 1.4 bytecode (including generics,
> annotations, java-util-concurrent etc).
>
> So depending on Java 5 and JAXB2 is fine; we can just generate 1.4
> versions where we need to. It does mean that the build itself depends
> on Java 5 but thats no big deal.
>
>
> > If the team think this is a good idea or have comments we can place
> > a cut of the code somewhere for review or we can make it a tooling
> > project and examine maybe how we could document the lw-container to
> > make it a good basis to writing a component and passing it
> > parameters, also we might want to see if some of the service-
> > components could be modified to be able to use the stored assets if
> > available.
> >
> > All comments and thoughts are welcome :)
>
> Sounds awesome - bring it on Philip! :)
>
> By all means just check the code into the Apache ServiceMix repo if
> you want. If you didn't write all the code we'll need CLAs to be on
> file at Apache.
>
> I owe you a few more beers for this :)
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
>
Re: JBI Deployer
Posted by James Strachan <ja...@gmail.com>.
On 17 Jan 2006, at 11:11, Philip Dodds wrote:
> We've been working on a re-usable deployment plugin for eclipse to
> try and simplify the process of create components and actually
> making them re-usable. The basic idea is fairly simple, when you
> build you JBI component, whether it be a binding component or a
> service engine you include a components.xml in the META-INF
> directory, which holds information about your component, and
> example of which is below:
>
> <components>
> <component type="binding-component">
>
> <componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid>
> <name>Groovy Script</name>
> <description>
> A component that can be deployed with an embedded Groovy Script
> </description>
> <assets>
> <embeddedArtifact name="script.groovy" extension="groovy"
> description="Your Groovy Script" />
> <parameter name="exampleparameter" defaultValue="haha"
>
> description="Example parameter"/>
> <connection default="true" name="defaultDestination"
>
> description="Default destination" mep="robustInOnly" />
> </assets>
> </component>
>
> In essence the idea of your components.xml is to describe your
> components, which can be either binding-components or service-
> engine, you can also define embedded artifacts which are files you
> expect to be bundles with either your service engine or binding-
> component, there is also space for parameters and also connections
> to other services. The idea behind this is to express your
> requirements for your component so that someone knows what they
> need to provide to get your working, the idea here is to make your
> component re-usable without needing the source code.
>
> Then basically we have two projects, one which is the descriptors
> for this components.xml and also a file called assets.xml and the
> second is an eclipse plugin that you can install and then register
> your components with, once you have the eclipse plugin installed
> in your eclipse you basically can goto preferences in eclipse and
> add all the packaged JBI components, basically those JBI
> components with a jbi.xml that are your usual stuff but also with a
> components.xml in there. Once you have registered them you can
> create a project and add a file with the extension .jbi, this will
> open the JBI deployer which is basically just a GEF diagramming
> component, however you will see you components (as registered from
> your components.xml) in the pallette, if you drop one on the canvas
> you will be able to configure the settings (those also defined in
> the components.xml) and therefore configure a re-usable JBI
> component. If you component is a service engine you will see
> component and be able to press the + button to create service units
> inside, note that in this case you can gather parameters at a
> service unit by added parameters etc at the service unit level ie:
>
> <component type="service-engine">
> <componentUuid>658c0460-7ee0-11da-ba83-0002a5d5c51c</
> componentUuid>
> <name>Translator</name>
> <description>
> Unity's transformation service engine
> </description>
> <serviceUnit>
> <assets>
> <embeddedArtifact name="translator.xml" extension="trslr"
> description="Translator Configuration" />
> <parameter name="exampleparameter" defaultValue="haha"
> description="Example parameter"/>
> <connection default="true" name="defaultDestination"
> description="Default destination"
> mep="robustInOnly" />
> </assets>
> </serviceUnit>
> </component>
> </components>
>
> Once you have set up your digram as you want it you can right click
> on a component or service assembly and choose deploy, this will
> create the component zips by basically exploding the base jar
> (which the components.xml) and creating a new component injecting
> both the embeddedArtifacts and also the assets (which are the
> parameters gathered from the deployment editor), therefore you
> would have META-INF/stored-assets.xml in either your binding-
> component or your service unit ie.
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <storedAssets> <artifactReference><name>script.groovy</
> name><path>whizbang.groovy</path></
> artifactReference><resourceReference><name>defaultDestination</
> name><resource xmlns:ns3=" http://openuri.org">ns3:newService2</
> resource></resourceReference><serviceName xmlns:ns3="http://
> openuri.org">ns3:newService</serviceName></storedAssets>
>
> In the descriptor package with then supply a simple
> StoredAssetFactory you can give either your service unit deploy
> path to or your component context to get your assets back.
>
> The basic idea here is to make the packaging of a JBI component or
> re-use and also the deployment of complex patterns easier with a
> graphical environment and a mechanism for exposing your code and
> requesting the artifacts etc you want.
>
> We (Unity Systems) have been working on this for the past couple of
> months and believe that the ServiceMix project would benefit from
> this style of deployment as it would enable easier configuration
> and deployment. There are a couple of downsides first is it was
> written for Java 5 and the second is a dependency on JAXB2.
Awesome!
FWIW thanks to the retrotranslator project - and the maven2 plugin -
we can actually generate 1.4 jars for Java 5 code and JAXB2 HEAD
works on it!
http://retrotranslator.sourceforge.net/
Many thanks to Kohsuke from the JAXB team for helping fix JAXB/JAXP
and Hiram for the m2 retrotranslator plugin (with lots of help from
Brett) and mostly for Taras for doing all the hard work of
translating 1.5 code into working 1.4 bytecode (including generics,
annotations, java-util-concurrent etc).
So depending on Java 5 and JAXB2 is fine; we can just generate 1.4
versions where we need to. It does mean that the build itself depends
on Java 5 but thats no big deal.
> If the team think this is a good idea or have comments we can place
> a cut of the code somewhere for review or we can make it a tooling
> project and examine maybe how we could document the lw-container to
> make it a good basis to writing a component and passing it
> parameters, also we might want to see if some of the service-
> components could be modified to be able to use the stored assets if
> available.
>
> All comments and thoughts are welcome :)
Sounds awesome - bring it on Philip! :)
By all means just check the code into the Apache ServiceMix repo if
you want. If you didn't write all the code we'll need CLAs to be on
file at Apache.
I owe you a few more beers for this :)
James
-------
http://radio.weblogs.com/0112098/
Re: JBI Deployer
Posted by Philip Dodds <ph...@gmail.com>.
Its a good idea, one of the reasons we didn't do this was that you can
create jar which contains more than one JBI component and therefore you can
reference different jbi.xml's for different componets, this was to allow a
situation where you might want to bundle a set of small/similar components
in a single JAR bundle, in this case each of your component tags can refer
to the location of the file that you wish to be the switched to the
jbi.xmlwhen deployed.
ie.
<components>
<component descriptor="component1-jbi.xml">
....
</component>
<component descriptor="component2-jbi.xml">
</component>
</component>
in this case you would have two components in the palette and during the
deploy you would switch the component1-jbi.xml to be the jbi.xml.
P
On 1/17/06, Hossam Karim <hr...@gmail.com> wrote:
>
> Philip,
>
> Why not use the provided JBI schema to describe your design time
> properties,
> something like:
>
>
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <jbi xmlns="http://java.sun.com/xml/ns/jbi"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
> xmlns:ext="http://www.example.org/jbi/extension"
>
> xsi:schemaLocation="http://java.sun.com/xml/ns/jbi ./jbi.xsd"
> version="1">
>
> <component type="binding-component">
>
> <identification>
>
> <name>GroovyScript</name>
>
> <description>A component that can be deployed with an embedded
> Groovy
> Script</description>
>
> </identification>
>
>
> <component-class-name>org.example.jbi.GroovyScriptBinding
> </component-class-n
> ame>
>
> <component-class-path>
>
> <path-element>.</path-element>
>
> </component-class-path>
>
>
> <bootstrap-class-name>org.example.jbi.GroovyScriptBootstrap
> </bootstrap-class
> -name>
>
> <bootstrap-class-path>
>
> <path-element>.</path-element>
>
> </bootstrap-class-path>
>
> <ext:component>
>
> <componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid>
>
> <assets>
>
> <embeddedArtifact name="script.groovy" extension="groovy"
> description="Your Groovy Script"/>
>
> <parameter name="exampleparameter" defaultValue="haha"
> description="Example parameter"/>
>
> <connection default="true" name="defaultDestination"
> description="Default destination" mep="robustInOnly"/>
>
> </assets>
>
> </ext:component>
>
> </component>
>
> </jbi>
>
>
>
> So the document would be reusable for both design time and deployment.
>
>
>
> My team is using a similar approach. We created a UML 2.0 profile for JBI;
> used deployment diagrams to define components and related artifacts,
> annotating them using the profile stereotypes. We then export the model
> into
> an XMI document, and at build time, we run an XQuery against the exported
> document to generate the descriptors.
>
>
>
> Cheers,
>
> Hossam Karim
>
>
>
> _____
>
> From: Philip Dodds [mailto:philip.dodds@gmail.com]
> Sent: Tuesday, January 17, 2006 9:12 PM
> To: servicemix-dev@geronimo.apache.org
> Subject: JBI Deployer
>
>
>
> We've been working on a re-usable deployment plugin for eclipse to try and
> simplify the process of create components and actually making them
> re-usable. The basic idea is fairly simple, when you build you JBI
> component, whether it be a binding component or a service engine you
> include a components.xml in the META-INF directory, which holds
> information
> about your component, and example of which is below:
>
> <components>
> <component type="binding-component">
>
> <componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid>
> <name>Groovy Script</name>
> <description>
> A component that can be deployed with an embedded Groovy Script
> </description>
> <assets>
> <embeddedArtifact name="script.groovy" extension="groovy"
> description="Your Groovy Script" />
> <parameter name="exampleparameter" defaultValue="haha"
>
> description="Example parameter"/>
> <connection default="true" name="defaultDestination"
>
> description="Default destination" mep="robustInOnly" />
> </assets>
> </component>
>
> In essence the idea of your components.xml is to describe your components,
> which can be either binding-components or service-engine, you can also
> define embedded artifacts which are files you expect to be bundles with
> either your service engine or binding-component, there is also space for
> parameters and also connections to other services. The idea behind this
> is
> to express your requirements for your component so that someone knows what
> they need to provide to get your working, the idea here is to make your
> component re-usable without needing the source code.
>
> Then basically we have two projects, one which is the descriptors for
> this
> components.xml and also a file called assets.xml and the second is an
> eclipse plugin that you can install and then register your components
> with,
> once you have the eclipse plugin installed in your eclipse you basically
> can
> goto preferences in eclipse and add all the packaged JBI components,
> basically those JBI components with a jbi.xml that are your usual stuff
> but
> also with a components.xml in there. Once you have registered them you
> can
> create a project and add a file with the extension .jbi, this will open
> the
> JBI deployer which is basically just a GEF diagramming component, however
> you will see you components (as registered from your components.xml) in
> the
> pallette, if you drop one on the canvas you will be able to configure the
> settings (those also defined in the components.xml) and therefore
> configure
> a re-usable JBI component. If you component is a service engine you will
> see component and be able to press the + button to create service units
> inside, note that in this case you can gather parameters at a service
> unit
> by added parameters etc at the service unit level ie:
>
> <component type="service-engine">
> <componentUuid>658c0460-7ee0-11da-ba83-0002a5d5c51c</componentUuid>
> <name>Translator</name>
> <description>
> Unity's transformation service engine
> </description>
> <serviceUnit>
> <assets>
> <embeddedArtifact name="translator.xml" extension="trslr"
> description="Translator Configuration" />
> <parameter name="exampleparameter" defaultValue="haha"
> description="Example parameter"/>
> <connection default="true" name="defaultDestination"
> description="Default destination"
> mep="robustInOnly" />
> </assets>
> </serviceUnit>
> </component>
> </components>
>
> Once you have set up your digram as you want it you can right click on a
> component or service assembly and choose deploy, this will create the
> component zips by basically exploding the base jar (which the
> components.xml) and creating a new component injecting both the
> embeddedArtifacts and also the assets (which are the parameters gathered
> from the deployment editor), therefore you would have
> META-INF/stored-assets.xml in either your binding-component or your
> service
> unit ie.
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <storedAssets>
> <artifactReference><name>script.groovy</name><path>whizbang.groovy
> </path></a
>
> rtifactReference><resourceReference><name>defaultDestination</name><resource
> xmlns:ns3="
> http://openuri.org"
> >ns3:newService2</resource></resourceReference><serviceNa
> me
> xmlns:ns3="http://openuri.org">ns3:newService</serviceName></storedAssets>
>
> In the descriptor package with then supply a simple StoredAssetFactory you
> can give either your service unit deploy path to or your component context
> to get your assets back.
>
> The basic idea here is to make the packaging of a JBI component or re-use
> and also the deployment of complex patterns easier with a graphical
> environment and a mechanism for exposing your code and requesting the
> artifacts etc you want.
>
> We (Unity Systems) have been working on this for the past couple of months
> and believe that the ServiceMix project would benefit from this style of
> deployment as it would enable easier configuration and deployment. There
> are a couple of downsides first is it was written for Java 5 and the
> second
> is a dependency on JAXB2.
>
> If the team think this is a good idea or have comments we can place a cut
> of
> the code somewhere for review or we can make it a tooling project and
> examine maybe how we could document the lw-container to make it a good
> basis
> to writing a component and passing it parameters, also we might want to
> see if some of the service-components could be modified to be able to use
> the stored assets if available.
>
> All comments and thoughts are welcome :)
>
> Cheers
>
> P
>
>
>
RE: JBI Deployer
Posted by Hossam Karim <hr...@gmail.com>.
Philip,
Why not use the provided JBI schema to describe your design time properties,
something like:
<?xml version="1.0" encoding="UTF-8"?>
<jbi xmlns="http://java.sun.com/xml/ns/jbi"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ext="http://www.example.org/jbi/extension"
xsi:schemaLocation="http://java.sun.com/xml/ns/jbi ./jbi.xsd" version="1">
<component type="binding-component">
<identification>
<name>GroovyScript</name>
<description>A component that can be deployed with an embedded Groovy
Script</description>
</identification>
<component-class-name>org.example.jbi.GroovyScriptBinding</component-class-n
ame>
<component-class-path>
<path-element>.</path-element>
</component-class-path>
<bootstrap-class-name>org.example.jbi.GroovyScriptBootstrap</bootstrap-class
-name>
<bootstrap-class-path>
<path-element>.</path-element>
</bootstrap-class-path>
<ext:component>
<componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid>
<assets>
<embeddedArtifact name="script.groovy" extension="groovy"
description="Your Groovy Script"/>
<parameter name="exampleparameter" defaultValue="haha"
description="Example parameter"/>
<connection default="true" name="defaultDestination"
description="Default destination" mep="robustInOnly"/>
</assets>
</ext:component>
</component>
</jbi>
So the document would be reusable for both design time and deployment.
My team is using a similar approach. We created a UML 2.0 profile for JBI;
used deployment diagrams to define components and related artifacts,
annotating them using the profile stereotypes. We then export the model into
an XMI document, and at build time, we run an XQuery against the exported
document to generate the descriptors.
Cheers,
Hossam Karim
_____
From: Philip Dodds [mailto:philip.dodds@gmail.com]
Sent: Tuesday, January 17, 2006 9:12 PM
To: servicemix-dev@geronimo.apache.org
Subject: JBI Deployer
We've been working on a re-usable deployment plugin for eclipse to try and
simplify the process of create components and actually making them
re-usable. The basic idea is fairly simple, when you build you JBI
component, whether it be a binding component or a service engine you
include a components.xml in the META-INF directory, which holds information
about your component, and example of which is below:
<components>
<component type="binding-component">
<componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid>
<name>Groovy Script</name>
<description>
A component that can be deployed with an embedded Groovy Script
</description>
<assets>
<embeddedArtifact name="script.groovy" extension="groovy"
description="Your Groovy Script" />
<parameter name="exampleparameter" defaultValue="haha"
description="Example parameter"/>
<connection default="true" name="defaultDestination"
description="Default destination" mep="robustInOnly" />
</assets>
</component>
In essence the idea of your components.xml is to describe your components,
which can be either binding-components or service-engine, you can also
define embedded artifacts which are files you expect to be bundles with
either your service engine or binding-component, there is also space for
parameters and also connections to other services. The idea behind this is
to express your requirements for your component so that someone knows what
they need to provide to get your working, the idea here is to make your
component re-usable without needing the source code.
Then basically we have two projects, one which is the descriptors for this
components.xml and also a file called assets.xml and the second is an
eclipse plugin that you can install and then register your components with,
once you have the eclipse plugin installed in your eclipse you basically can
goto preferences in eclipse and add all the packaged JBI components,
basically those JBI components with a jbi.xml that are your usual stuff but
also with a components.xml in there. Once you have registered them you can
create a project and add a file with the extension .jbi, this will open the
JBI deployer which is basically just a GEF diagramming component, however
you will see you components (as registered from your components.xml) in the
pallette, if you drop one on the canvas you will be able to configure the
settings (those also defined in the components.xml) and therefore configure
a re-usable JBI component. If you component is a service engine you will
see component and be able to press the + button to create service units
inside, note that in this case you can gather parameters at a service unit
by added parameters etc at the service unit level ie:
<component type="service-engine">
<componentUuid>658c0460-7ee0-11da-ba83-0002a5d5c51c</componentUuid>
<name>Translator</name>
<description>
Unity's transformation service engine
</description>
<serviceUnit>
<assets>
<embeddedArtifact name="translator.xml" extension="trslr"
description="Translator Configuration" />
<parameter name="exampleparameter" defaultValue="haha"
description="Example parameter"/>
<connection default="true" name="defaultDestination"
description="Default destination"
mep="robustInOnly" />
</assets>
</serviceUnit>
</component>
</components>
Once you have set up your digram as you want it you can right click on a
component or service assembly and choose deploy, this will create the
component zips by basically exploding the base jar (which the
components.xml) and creating a new component injecting both the
embeddedArtifacts and also the assets (which are the parameters gathered
from the deployment editor), therefore you would have
META-INF/stored-assets.xml in either your binding-component or your service
unit ie.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<storedAssets>
<artifactReference><name>script.groovy</name><path>whizbang.groovy</path></a
rtifactReference><resourceReference><name>defaultDestination</name><resource
xmlns:ns3="
http://openuri.org">ns3:newService2</resource></resourceReference><serviceNa
me
xmlns:ns3="http://openuri.org">ns3:newService</serviceName></storedAssets>
In the descriptor package with then supply a simple StoredAssetFactory you
can give either your service unit deploy path to or your component context
to get your assets back.
The basic idea here is to make the packaging of a JBI component or re-use
and also the deployment of complex patterns easier with a graphical
environment and a mechanism for exposing your code and requesting the
artifacts etc you want.
We (Unity Systems) have been working on this for the past couple of months
and believe that the ServiceMix project would benefit from this style of
deployment as it would enable easier configuration and deployment. There
are a couple of downsides first is it was written for Java 5 and the second
is a dependency on JAXB2.
If the team think this is a good idea or have comments we can place a cut of
the code somewhere for review or we can make it a tooling project and
examine maybe how we could document the lw-container to make it a good basis
to writing a component and passing it parameters, also we might want to
see if some of the service-components could be modified to be able to use
the stored assets if available.
All comments and thoughts are welcome :)
Cheers
P