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/
