[osee-dev] RE: Remote Event Service Re-Arch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

[osee-dev] RE: Remote Event Service Re-Arch

From: Ken Aguilar <ken.aguilar@xxxxxxxxx>
Date: Mon, 27 Jul 2009 12:31:11 -0700
Delivered-to: osee-dev@xxxxxxxxxxx
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=A+RMAY/gYeqq+0mj/hUOsC43lQBLMrX/WgeZ1xhg/7bu8QHgeLoqjiM6pwEUqZ+Irg dRV7DtG18pTdgL35VbU8mbfqtyBCtxlUAtgBjXRLwihzszImgyhprwrex4yuIn4nXxOD 3sgzMZnlohGhPcJYHmQVx+I4iPm5uDvEU4koc=
List-archive: <https://dev.eclipse.org/mailman/private/osee-dev>
List-help: <mailto:osee-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/osee-dev>, <mailto:osee-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/listinfo/osee-dev>, <mailto:osee-dev-request@eclipse.org?subject=unsubscribe>

I think ActiveMQ and Camel is the way to go. A messaging system gives us more flexibility than a RMI approach. A lot of the capabilities in ActiveMQ seem to be a perfect fit for the remote event service. Camel should help hide a lot of the boilerplate code that would be needed for each entity that needs to receive remote events.

--
Ken J. aguilar
Embedded Systems Engineer

Prev by Date: [osee-dev] RE: Remote Event Service Re-Arch
Next by Date: [osee-dev] Preparations for migrating more functionality to the server
Previous by thread: RE: [osee-dev] RE: Remote Event Service Re-Arch
Next by thread: [osee-dev] Preparations for migrating more functionality to the server
Index(es):
- Date
- Thread

Breadcrumbs