You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Thiébault Benoît <de...@artenum.com> on 2010/11/04 09:51:33 UTC
EventAdmin best pratices
Hi everyone,
I have read this very interesting article regarding OSGi EventAdmin Service (http://wiki.eclipse.org/E4/Event_Processing) and one of the references provided( http://www.dynamicjava.org/articles/osgi-compendium/event-admin-service).
In the latter, it is said that
"Placing non-primitive types (types other than string and and the eight primitive types) as Event Property values is far form being considered a best practice since in cases where the handler of your event exists in a different environment (different VM for example), the handler might not be able to deserialize the property."
While I do agree with the deserialization problem, I wonder what the best practices are to transfer objects from one bundle to another.
For instance, if I have one complex object that is setup by a given bundle and processed by a second one, how would you transfer the object? Using Services might answer the problem but the application I am developing should transfer a lot of objects between bundles and creating a Service for each one of them could be a painful task.
Kind regards
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: EventAdmin best pratices
Posted by Guillaume Nodet <gn...@gmail.com>.
You may want to have a look at Apache ServiceMix NMR which I think
could be a perfect fit for your use case. Coupled with Apache Camel
(for accessing various protocols, transformation and all).
The following blog post could give you a good introduction at what it
is: http://trenaman.blogspot.com/2010/08/easy-useful-nmr-monsieur-nodet-vous.html
2010/11/4 Thiébault Benoît <de...@artenum.com>:
> Hi everyone,
>
> I have read this very interesting article regarding OSGi EventAdmin Service (http://wiki.eclipse.org/E4/Event_Processing) and one of the references provided( http://www.dynamicjava.org/articles/osgi-compendium/event-admin-service).
>
> In the latter, it is said that
> "Placing non-primitive types (types other than string and and the eight primitive types) as Event Property values is far form being considered a best practice since in cases where the handler of your event exists in a different environment (different VM for example), the handler might not be able to deserialize the property."
>
> While I do agree with the deserialization problem, I wonder what the best practices are to transfer objects from one bundle to another.
> For instance, if I have one complex object that is setup by a given bundle and processed by a second one, how would you transfer the object? Using Services might answer the problem but the application I am developing should transfer a lot of objects between bundles and creating a Service for each one of them could be a painful task.
>
> Kind regards
>
> Ben
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: EventAdmin best pratices
Posted by Steven Siebert <sm...@gmail.com>.
Guillaume - nice article and great work on the NMR =)
I wasn't aware of these - thanks. It's really neat you can use/embed the
NMR without ServiceMix. Time to play =)
On Thu, Nov 4, 2010 at 9:30 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> Yeah, you don't need the whole ServiceMix, but you'd still need a few
> bundles.
> The xml at
> http://repo2.maven.org/maven2/org/apache/servicemix/nmr/apache-servicemix-nmr/1.2.0/apache-servicemix-nmr-1.2.0-features.xml
> can give you a good start as what is needed. The nmr feature inside
> will give you the list of required bundles.
>
> 2010/11/4 Thiébault Benoît <de...@artenum.com>:
> > Hi and thank you for your answers.
> >
> > Right now, my application is not distributed, so it's just one JVM.
> > But it is planned in the future to make a distributed version... So I
> should chose wisely on what messaging system to rely.
> >
> > I read Guillaume article about NMR and went on Service Mix web page. My
> first impression is that it is a very big and complex stuff :-), while
> EventAdmin is included in OSGi. If I don't need all Service Mixes, can I
> just pick one?
> >
> > Ben
> >
> > Le 4 nov. 2010 à 11:02, Steven Siebert a écrit :
> >
> >> Hi Ben,
> >>
> >> His statement is true, there could be a few cases where you won't be
> able to
> >> deserialize properly given a different environment, but this sort of
> thing
> >> should only really be an issue in a distributed context or possibly if
> you
> >> had some local classloader issues. From what I get from your statement,
> it
> >> appears your pub/sub operations are all within the same runtime? I
> don't
> >> think this could be an issue.
> >>
> >> Even if you did have a distributed pub/sub model using the EventAdmin
> >> service, other EE spec services, roll-your-own RMI protocol, etc...it is
> >> often the case that ensuring that the dependent libraries or descriptors
> are
> >> available to the other environment, things will work as expected. If
> this
> >> is the case, I'm sure you would ensure this would be available on
> deployment
> >> in some way or another.
> >>
> >> As Guillaume pointed out, an ESB might be a good match for you (one with
> an
> >> NMR would be especially good if you are doing a lot of local work).
> >> But...even then...you're having to providing some sort of "hinting" on
> how
> >> to deserialize an object (ie, [abstract] wsdl's, etc). So...what did
> you
> >> gain?
> >>
> >> I guess my point is that this is an extension of the standard "it
> depends"
> >> answer, IMO. If using the EventAdmin service works for your use case,
> given
> >> all considerations of corner cases and future scale-out requirements,
> then
> >> go for it. For many of my projects, a non-reliable service like many
> >> EventAdmin implementations is not acceptable but probably would have
> scaled
> >> well even over a distributed context. =) I find it easier/better in
> the
> >> long run to keep the architecture as simple as possible while leveraging
> >> standard services...and EventAdmin service would fit in a simple local
> >> pub/sub model to me for many cases. This is just my opinion, though...
> >>
> >> Steve
> >>
> >> On Thu, Nov 4, 2010 at 4:51 AM, Thiébault Benoît <de...@artenum.com>
> wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> I have read this very interesting article regarding OSGi EventAdmin
> Service
> >>> (http://wiki.eclipse.org/E4/Event_Processing) and one of the
> references
> >>> provided(
> >>>
> http://www.dynamicjava.org/articles/osgi-compendium/event-admin-service).
> >>>
> >>> In the latter, it is said that
> >>> "Placing non-primitive types (types other than string and and the eight
> >>> primitive types) as Event Property values is far form being considered
> a
> >>> best practice since in cases where the handler of your event exists in
> a
> >>> different environment (different VM for example), the handler might not
> be
> >>> able to deserialize the property."
> >>>
> >>> While I do agree with the deserialization problem, I wonder what the
> best
> >>> practices are to transfer objects from one bundle to another.
> >>> For instance, if I have one complex object that is setup by a given
> bundle
> >>> and processed by a second one, how would you transfer the object? Using
> >>> Services might answer the problem but the application I am developing
> should
> >>> transfer a lot of objects between bundles and creating a Service for
> each
> >>> one of them could be a painful task.
> >>>
> >>> Kind regards
> >>>
> >>> Ben
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: EventAdmin best pratices
Posted by Guillaume Nodet <gn...@gmail.com>.
Yeah, you don't need the whole ServiceMix, but you'd still need a few bundles.
The xml at http://repo2.maven.org/maven2/org/apache/servicemix/nmr/apache-servicemix-nmr/1.2.0/apache-servicemix-nmr-1.2.0-features.xml
can give you a good start as what is needed. The nmr feature inside
will give you the list of required bundles.
2010/11/4 Thiébault Benoît <de...@artenum.com>:
> Hi and thank you for your answers.
>
> Right now, my application is not distributed, so it's just one JVM.
> But it is planned in the future to make a distributed version... So I should chose wisely on what messaging system to rely.
>
> I read Guillaume article about NMR and went on Service Mix web page. My first impression is that it is a very big and complex stuff :-), while EventAdmin is included in OSGi. If I don't need all Service Mixes, can I just pick one?
>
> Ben
>
> Le 4 nov. 2010 à 11:02, Steven Siebert a écrit :
>
>> Hi Ben,
>>
>> His statement is true, there could be a few cases where you won't be able to
>> deserialize properly given a different environment, but this sort of thing
>> should only really be an issue in a distributed context or possibly if you
>> had some local classloader issues. From what I get from your statement, it
>> appears your pub/sub operations are all within the same runtime? I don't
>> think this could be an issue.
>>
>> Even if you did have a distributed pub/sub model using the EventAdmin
>> service, other EE spec services, roll-your-own RMI protocol, etc...it is
>> often the case that ensuring that the dependent libraries or descriptors are
>> available to the other environment, things will work as expected. If this
>> is the case, I'm sure you would ensure this would be available on deployment
>> in some way or another.
>>
>> As Guillaume pointed out, an ESB might be a good match for you (one with an
>> NMR would be especially good if you are doing a lot of local work).
>> But...even then...you're having to providing some sort of "hinting" on how
>> to deserialize an object (ie, [abstract] wsdl's, etc). So...what did you
>> gain?
>>
>> I guess my point is that this is an extension of the standard "it depends"
>> answer, IMO. If using the EventAdmin service works for your use case, given
>> all considerations of corner cases and future scale-out requirements, then
>> go for it. For many of my projects, a non-reliable service like many
>> EventAdmin implementations is not acceptable but probably would have scaled
>> well even over a distributed context. =) I find it easier/better in the
>> long run to keep the architecture as simple as possible while leveraging
>> standard services...and EventAdmin service would fit in a simple local
>> pub/sub model to me for many cases. This is just my opinion, though...
>>
>> Steve
>>
>> On Thu, Nov 4, 2010 at 4:51 AM, Thiébault Benoît <de...@artenum.com> wrote:
>>
>>> Hi everyone,
>>>
>>> I have read this very interesting article regarding OSGi EventAdmin Service
>>> (http://wiki.eclipse.org/E4/Event_Processing) and one of the references
>>> provided(
>>> http://www.dynamicjava.org/articles/osgi-compendium/event-admin-service).
>>>
>>> In the latter, it is said that
>>> "Placing non-primitive types (types other than string and and the eight
>>> primitive types) as Event Property values is far form being considered a
>>> best practice since in cases where the handler of your event exists in a
>>> different environment (different VM for example), the handler might not be
>>> able to deserialize the property."
>>>
>>> While I do agree with the deserialization problem, I wonder what the best
>>> practices are to transfer objects from one bundle to another.
>>> For instance, if I have one complex object that is setup by a given bundle
>>> and processed by a second one, how would you transfer the object? Using
>>> Services might answer the problem but the application I am developing should
>>> transfer a lot of objects between bundles and creating a Service for each
>>> one of them could be a painful task.
>>>
>>> Kind regards
>>>
>>> Ben
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: EventAdmin best pratices
Posted by Thiébault Benoît <de...@artenum.com>.
Hi and thank you for your answers.
Right now, my application is not distributed, so it's just one JVM.
But it is planned in the future to make a distributed version... So I should chose wisely on what messaging system to rely.
I read Guillaume article about NMR and went on Service Mix web page. My first impression is that it is a very big and complex stuff :-), while EventAdmin is included in OSGi. If I don't need all Service Mixes, can I just pick one?
Ben
Le 4 nov. 2010 à 11:02, Steven Siebert a écrit :
> Hi Ben,
>
> His statement is true, there could be a few cases where you won't be able to
> deserialize properly given a different environment, but this sort of thing
> should only really be an issue in a distributed context or possibly if you
> had some local classloader issues. From what I get from your statement, it
> appears your pub/sub operations are all within the same runtime? I don't
> think this could be an issue.
>
> Even if you did have a distributed pub/sub model using the EventAdmin
> service, other EE spec services, roll-your-own RMI protocol, etc...it is
> often the case that ensuring that the dependent libraries or descriptors are
> available to the other environment, things will work as expected. If this
> is the case, I'm sure you would ensure this would be available on deployment
> in some way or another.
>
> As Guillaume pointed out, an ESB might be a good match for you (one with an
> NMR would be especially good if you are doing a lot of local work).
> But...even then...you're having to providing some sort of "hinting" on how
> to deserialize an object (ie, [abstract] wsdl's, etc). So...what did you
> gain?
>
> I guess my point is that this is an extension of the standard "it depends"
> answer, IMO. If using the EventAdmin service works for your use case, given
> all considerations of corner cases and future scale-out requirements, then
> go for it. For many of my projects, a non-reliable service like many
> EventAdmin implementations is not acceptable but probably would have scaled
> well even over a distributed context. =) I find it easier/better in the
> long run to keep the architecture as simple as possible while leveraging
> standard services...and EventAdmin service would fit in a simple local
> pub/sub model to me for many cases. This is just my opinion, though...
>
> Steve
>
> On Thu, Nov 4, 2010 at 4:51 AM, Thiébault Benoît <de...@artenum.com> wrote:
>
>> Hi everyone,
>>
>> I have read this very interesting article regarding OSGi EventAdmin Service
>> (http://wiki.eclipse.org/E4/Event_Processing) and one of the references
>> provided(
>> http://www.dynamicjava.org/articles/osgi-compendium/event-admin-service).
>>
>> In the latter, it is said that
>> "Placing non-primitive types (types other than string and and the eight
>> primitive types) as Event Property values is far form being considered a
>> best practice since in cases where the handler of your event exists in a
>> different environment (different VM for example), the handler might not be
>> able to deserialize the property."
>>
>> While I do agree with the deserialization problem, I wonder what the best
>> practices are to transfer objects from one bundle to another.
>> For instance, if I have one complex object that is setup by a given bundle
>> and processed by a second one, how would you transfer the object? Using
>> Services might answer the problem but the application I am developing should
>> transfer a lot of objects between bundles and creating a Service for each
>> one of them could be a painful task.
>>
>> Kind regards
>>
>> Ben
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: EventAdmin best pratices
Posted by Steven Siebert <sm...@gmail.com>.
Hi Ben,
His statement is true, there could be a few cases where you won't be able to
deserialize properly given a different environment, but this sort of thing
should only really be an issue in a distributed context or possibly if you
had some local classloader issues. From what I get from your statement, it
appears your pub/sub operations are all within the same runtime? I don't
think this could be an issue.
Even if you did have a distributed pub/sub model using the EventAdmin
service, other EE spec services, roll-your-own RMI protocol, etc...it is
often the case that ensuring that the dependent libraries or descriptors are
available to the other environment, things will work as expected. If this
is the case, I'm sure you would ensure this would be available on deployment
in some way or another.
As Guillaume pointed out, an ESB might be a good match for you (one with an
NMR would be especially good if you are doing a lot of local work).
But...even then...you're having to providing some sort of "hinting" on how
to deserialize an object (ie, [abstract] wsdl's, etc). So...what did you
gain?
I guess my point is that this is an extension of the standard "it depends"
answer, IMO. If using the EventAdmin service works for your use case, given
all considerations of corner cases and future scale-out requirements, then
go for it. For many of my projects, a non-reliable service like many
EventAdmin implementations is not acceptable but probably would have scaled
well even over a distributed context. =) I find it easier/better in the
long run to keep the architecture as simple as possible while leveraging
standard services...and EventAdmin service would fit in a simple local
pub/sub model to me for many cases. This is just my opinion, though...
Steve
On Thu, Nov 4, 2010 at 4:51 AM, Thiébault Benoît <de...@artenum.com> wrote:
> Hi everyone,
>
> I have read this very interesting article regarding OSGi EventAdmin Service
> (http://wiki.eclipse.org/E4/Event_Processing) and one of the references
> provided(
> http://www.dynamicjava.org/articles/osgi-compendium/event-admin-service).
>
> In the latter, it is said that
> "Placing non-primitive types (types other than string and and the eight
> primitive types) as Event Property values is far form being considered a
> best practice since in cases where the handler of your event exists in a
> different environment (different VM for example), the handler might not be
> able to deserialize the property."
>
> While I do agree with the deserialization problem, I wonder what the best
> practices are to transfer objects from one bundle to another.
> For instance, if I have one complex object that is setup by a given bundle
> and processed by a second one, how would you transfer the object? Using
> Services might answer the problem but the application I am developing should
> transfer a lot of objects between bundles and creating a Service for each
> one of them could be a painful task.
>
> Kind regards
>
> Ben
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>