Refactoring code to reduce the amount of code required to write full JBI components

[James Strachan <ja...@gmail.com>]

I was wondering about the minimal amount of code required to write a
nicely behaving JBI component with proper component, endpoint,
deployer and URI/EPR handling etc.

e.g. if we were to refactor more of the components in the
servicemix-components module into their own module like the jms, http
and jsr181 modules - what new code would be required. Or rather how
little could we get away with :)

So I was wondering if we could do a little bit of refactoring to
reduce the amount of code that is really needed to be written on each
component. (Some of the other components are way simpler than jms,
http and JSR181 support too such as the file component so the code
should hopefully be even simpler).

I've not had an coffee yet so please excuse any silly ideas but a
quick run through the code in the Jms and HTTP components with brief
looks at JSR181 led to the following thoughts...

* HttpBootstrap & JmsBootstrap are pretty much identical apart from
the configuration property (incidentally should HttpBootstrap use a
HttpConfiguration like JmsBootstrap?) so am wondering if we can push
more of its logic up to a base class - maybe allowing the
configuration object to be specified as a constructor argument?

* HttpLifecycle & JmsLifecycle have quite a few similarities. I wonder
could we refactor most of the code into the *Configuration and
*Endpoint classes so that we could basically share the same Lifecycle
classes in most components?

* Jms/HttpExternalEndpoint look pretty identical - just dependent on
their Jms/HttpEndpoint classes

* Jms/HttpResolvedEndpoint pretty much the same bar some constants -
maybe moving those into the *Endpoint or *Component classes might make
the code simpler?

* Jms/HttpSpringComponent - look about the same apart from the use of
Jms/HttpEndpoint - I wonder if generics could be used to share a
common base class? Basically the only real difference is the type of
the endpoint.

* Jms/HttpXBeanDeployer - we could maybe use a generic XBeanDeployer
which is parameterized on the type of the Endpoint and then call
*Endpoint.validate() to avoid needing to write a new class for this
unless its absolutely necessary (like it is for JSR181)?

I was really just trying to avoid as much of the boiler plate code as
possible so we could make more fully-JBI compliant components with as
little code as possible.

Am thinking the bare minimum would be something like the bootstrap,
component, configuration & endpoint classes with reusable base classes
for most of the other stuff then the consumer/producer classes for
doing the actual work.

Any other thoughts on how to reduce/simplify the amount of code required?
-- 

James
-------
http://radio.weblogs.com/0112098/

Re: Refactoring code to reduce the amount of code required to write full JBI components

[James Strachan <ja...@gmail.com>]

On 8/22/06, Guillaume Nodet <gn...@gmail.com> wrote:
> Comments inline
>
> On 8/22/06, James Strachan <ja...@gmail.com> wrote:
> > I was wondering about the minimal amount of code required to write a
> > nicely behaving JBI component with proper component, endpoint,
> > deployer and URI/EPR handling etc.
> >
> > e.g. if we were to refactor more of the components in the
> > servicemix-components module into their own module like the jms, http
> > and jsr181 modules - what new code would be required. Or rather how
> > little could we get away with :)
> >
> > So I was wondering if we could do a little bit of refactoring to
> > reduce the amount of code that is really needed to be written on each
> > component. (Some of the other components are way simpler than jms,
> > http and JSR181 support too such as the file component so the code
> > should hopefully be even simpler).
>
> Of course it would be nice.
> I think all your following points came from the fact that I added features
> to servicemix-http first (so not in servicemix-common / servicemix-soap)
> and then duplicated them in servicemix-http instead of refactoring them
> in some common code :(  My mistake.

No worries - my bad for choosing the wrong components to look at  :).
Its good to know servicemix-soap is the clean one to use as a template
when we start writing more components


> > I've not had an coffee yet so please excuse any silly ideas but a
> > quick run through the code in the Jms and HTTP components with brief
> > looks at JSR181 led to the following thoughts...
> >
> > * HttpBootstrap & JmsBootstrap are pretty much identical apart from
> > the configuration property (incidentally should HttpBootstrap use a
> > HttpConfiguration like JmsBootstrap?) so am wondering if we can push
> > more of its logic up to a base class - maybe allowing the
> > configuration object to be specified as a constructor argument?
>
> At first, they were inheriting a base class (BaseBootstrap in
> servicemix-common).
> The problem is that shared libraries are not available at bootstrap
> time according
> to the jbi spec (hence to ServiceMix too).  So we can not refactor much here :(

Damn! Thanks for the heads up.

It might be worth us putting comments in the bootstrap classes to warn
folks not to bother trying to refactor that code :)


> > * HttpLifecycle & JmsLifecycle have quite a few similarities. I wonder
> > could we refactor most of the code into the *Configuration and
> > *Endpoint classes so that we could basically share the same Lifecycle
> > classes in most components?
>
> Yeah maybe.  There are other ways too: refactor the component and the lifecycle
> in the same class (this would lead to one class less to implement) and / or
> have a base component for soap-enabled base component class which would
> retrieve the needed additional components (AuthenticationService,
> KeystoreManager).

Yeah - I was musing that too on the way to see a customer this
morning. It does seem like Spring support requires a slightly
different component and lifecycle. But given the simplicity of these 3
classes (lifecycle, component, spring component) maybe we can merge
the three together and put most of the work in the base class.

I did wonder about a reusable base class for Configuration too for
things like the authentication service & keystore manager.


> > * Jms/HttpExternalEndpoint look pretty identical - just dependent on
> > their Jms/HttpEndpoint classes
> >
> > * Jms/HttpResolvedEndpoint pretty much the same bar some constants -
> > maybe moving those into the *Endpoint or *Component classes might make
> > the code simpler?
> >
>
> Agreed, we could have only two classes for these

Great


> > * Jms/HttpSpringComponent - look about the same apart from the use of
> > Jms/HttpEndpoint - I wonder if generics could be used to share a
> > common base class? Basically the only real difference is the type of
> > the endpoint.
>
> Not sure, as the configuration, enpoint resolution and lifecycles are different.
> Also the use of generics will introduce a JDK 5 requirement, unless we
> use retrotranslator ;)

Yeah :)

I wonder if we bad a base class that combined the component &
lifecycle & spring stuff then had a separate endpoint then had plenty
of hooks we could mostly share the same code and just overload where
need be (and for simple components we'll have little work to do).


> > * Jms/HttpXBeanDeployer - we could maybe use a generic XBeanDeployer
> > which is parameterized on the type of the Endpoint and then call
> > *Endpoint.validate() to avoid needing to write a new class for this
> > unless its absolutely necessary (like it is for JSR181)?
>
> True also.
>
> >
> > I was really just trying to avoid as much of the boiler plate code as
> > possible so we could make more fully-JBI compliant components with as
> > little code as possible.
> >
> > Am thinking the bare minimum would be something like the bootstrap,
> > component, configuration & endpoint classes with reusable base classes
> > for most of the other stuff then the consumer/producer classes for
> > doing the actual work.
> >
> > Any other thoughts on how to reduce/simplify the amount of code required?
>
> We will also need to update the archetypes to reflect all this.

Yeah


> Note that usually, BC and SE have different features, where current BC all use
> the servicemix-soap module.  We could add some BC specific classes in
> servicemix-common and make servicemix-common dependant on servicemix-soap.
> Btw, both are packaged in servicemix-shared SharedLibrary, so there's no problem
> in doing that.

Cool. I guess for new things like a file or jabber component we should
mostly be reusing the servicemix-soap module so we could start (after
3.0 is out of the way) experimenting with that.


> I'd like to have 3.0 out asap, so I think it's time to create a 3.1
> branch so that
> new devs can happen there, and keep trunk for 3.0 until it is out.
> I'll start a new
> thread on that now.

Agreed

-- 

James
-------
http://radio.weblogs.com/0112098/

Re: Refactoring code to reduce the amount of code required to write full JBI components

[Guillaume Nodet <gn...@gmail.com>]

Comments inline

On 8/22/06, James Strachan <ja...@gmail.com> wrote:
> I was wondering about the minimal amount of code required to write a
> nicely behaving JBI component with proper component, endpoint,
> deployer and URI/EPR handling etc.
>
> e.g. if we were to refactor more of the components in the
> servicemix-components module into their own module like the jms, http
> and jsr181 modules - what new code would be required. Or rather how
> little could we get away with :)
>
> So I was wondering if we could do a little bit of refactoring to
> reduce the amount of code that is really needed to be written on each
> component. (Some of the other components are way simpler than jms,
> http and JSR181 support too such as the file component so the code
> should hopefully be even simpler).

Of course it would be nice.
I think all your following points came from the fact that I added features
to servicemix-http first (so not in servicemix-common / servicemix-soap)
and then duplicated them in servicemix-http instead of refactoring them
in some common code :(  My mistake.

>
> I've not had an coffee yet so please excuse any silly ideas but a
> quick run through the code in the Jms and HTTP components with brief
> looks at JSR181 led to the following thoughts...
>
> * HttpBootstrap & JmsBootstrap are pretty much identical apart from
> the configuration property (incidentally should HttpBootstrap use a
> HttpConfiguration like JmsBootstrap?) so am wondering if we can push
> more of its logic up to a base class - maybe allowing the
> configuration object to be specified as a constructor argument?

At first, they were inheriting a base class (BaseBootstrap in
servicemix-common).
The problem is that shared libraries are not available at bootstrap
time according
to the jbi spec (hence to ServiceMix too).  So we can not refactor much here :(
I'll take a look at the HttpBoostrap / HttpConfiguration problem.

>
> * HttpLifecycle & JmsLifecycle have quite a few similarities. I wonder
> could we refactor most of the code into the *Configuration and
> *Endpoint classes so that we could basically share the same Lifecycle
> classes in most components?

Yeah maybe.  There are other ways too: refactor the component and the lifecycle
in the same class (this would lead to one class less to implement) and / or
have a base component for soap-enabled base component class which would
retrieve the needed additional components (AuthenticationService,
KeystoreManager).

>
> * Jms/HttpExternalEndpoint look pretty identical - just dependent on
> their Jms/HttpEndpoint classes
>
> * Jms/HttpResolvedEndpoint pretty much the same bar some constants -
> maybe moving those into the *Endpoint or *Component classes might make
> the code simpler?
>

Agreed, we could have only two classes for these

> * Jms/HttpSpringComponent - look about the same apart from the use of
> Jms/HttpEndpoint - I wonder if generics could be used to share a
> common base class? Basically the only real difference is the type of
> the endpoint.

Not sure, as the configuration, enpoint resolution and lifecycles are different.
Also the use of generics will introduce a JDK 5 requirement, unless we
use retrotranslator ;)

>
> * Jms/HttpXBeanDeployer - we could maybe use a generic XBeanDeployer
> which is parameterized on the type of the Endpoint and then call
> *Endpoint.validate() to avoid needing to write a new class for this
> unless its absolutely necessary (like it is for JSR181)?

True also.

>
> I was really just trying to avoid as much of the boiler plate code as
> possible so we could make more fully-JBI compliant components with as
> little code as possible.
>
> Am thinking the bare minimum would be something like the bootstrap,
> component, configuration & endpoint classes with reusable base classes
> for most of the other stuff then the consumer/producer classes for
> doing the actual work.
>
> Any other thoughts on how to reduce/simplify the amount of code required?

We will also need to update the archetypes to reflect all this.

Note that usually, BC and SE have different features, where current BC all use
the servicemix-soap module.  We could add some BC specific classes in
servicemix-common and make servicemix-common dependant on servicemix-soap.
Btw, both are packaged in servicemix-shared SharedLibrary, so there's no problem
in doing that.

I'd like to have 3.0 out asap, so I think it's time to create a 3.1
branch so that
new devs can happen there, and keep trunk for 3.0 until it is out.
I'll start a new
thread on that now.

> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>


-- 
Cheers,
Guillaume Nodet