camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Taylor <ctalk...@ctalkobt.net>
Subject Re: Need advice on application architecture with camel
Date Tue, 05 Dec 2017 03:03:04 GMT
Actually after I sent my suggestions relalised he had asked in May of this
year - (was looking at an older email folder (since fixed)).  Hopefully
it's still useful...

On Mon, Dec 4, 2017 at 9:56 PM, Matthew Shaw <
Matthew.Shaw@ambulance.qld.gov.au> wrote:

> Sounds like he is doing message driven architecture. I would recommend a
> simple high level camel route (java dsl), which in-turn routes to a
> destination, based on structured message, which contains enough info for
> the event, including any dynamic stuff.
>
>
>
> -----Original Message-----
> From: Craig Taylor [mailto:ctalkobt@ctalkobt.net]
> Sent: Tuesday, 5 December 2017 12:47 PM
> To: users <users@camel.apache.org>
> Subject: Re: Need advice on application architecture with camel
>
> See http://camel.apache.org/loading-routes-from-xml-files.html for
> loading XML routes at runtime.
>
> For #1 consider using the DSL route creation.  It returns Java objects for
> each of the constituent parts.  The DSL does not have to be as 1 contiguous
> block so conditional logic can be applied to modify it at route creation
> time at startup.
>
> The question of whether to put them into the same context is probably more
> of a question on what the hardcoded routes represent versus the XML based
> routes.  Are there 2 separate business concepts being expressed or one? As
> with any design decision like this, opinions will vary.
>
> On Mon, May 29, 2017 at 8:55 AM, MaFo <effisucki1974@yahoo.com> wrote:
>
> > Hi
> >
> > I got the task to build an Event-Dispatching application and decided
> > to use camel as base framework.
> > Among others, I have the following requirements:
> >
> > 1) Some routes are hardcoded in the software, but the user can
> > configure some aspects of the route via a web gui (e.g. the condition
> > for a switch-block or the name of a field to look for).
> > 2) All other routes are not known at design time, the will be
> > specified by the customer AFTER the software has been delivered.
> > Therefore the application should be able to load routes from XML files
> > and/or from JAR files (via routebuilders or similar)
> >
> > So I have to collect routes from 3 sources: XML, JAR files and
> > dynamically build by JAVA DSL with input from webgui.
> >
> > How can I build my application so all those routes come together in
> > one context and can be monitored, e.g. with HAWT.IO?
> > Is it even recommended to put all those routes in the same context?
> >
> > Thanks for your help!
> >
> >
> >
> > --
> > View this message in context: http://camel.465427.n5.nabble.
> > com/Need-advice-on-application-architecture-with-camel-tp5801290.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
> >
>
>
>
> --
> -------------------------------------------
> Craig Taylor
> ctalkobt@ctalkobt.net
> This email, including any attachments sent with it, is confidential and
> for the sole use of the intended recipient(s). This confidentiality is not
> waived or lost, if you receive it and you are not the intended
> recipient(s), or if it is transmitted/received in error.
>
> Any unauthorised use, alteration, disclosure, distribution or review of
> this email is strictly prohibited. The information contained in this email,
> including any attachment sent with it, may be subject to a statutory duty
> of confidentiality if it relates to health service matters.
>
> If you are not the intended recipient(s), or if you have received this
> email in error, you are asked to immediately notify the sender. You should
> also delete this email, and any copies, from your computer system network
> and destroy any hard copies produced.
>
> If not an intended recipient of this email, you must not copy, distribute
> or take any action(s) that relies on it; any form of disclosure,
> modification, distribution and/or publication of this email is also
> prohibited.
>
> Although the Queensland Ambulance Service takes all reasonable steps to
> ensure this email does not contain malicious software, the Queensland
> Ambulance Service does not accept responsibility for the consequences if
> any person's computer inadvertently suffers any disruption to services,
> loss of information, harm or is infected with a virus, other malicious
> computer programme or code that may occur as a consequence of receiving
> this email.
>
> Unless stated otherwise, this email represents only the views of the
> sender and not the views of the Queensland Government.
>
> ************************************************************
> ********************
>
> The content presented in this publication is distributed by the Queensland
> Government as an information source only. The State of Queensland makes no
> statements, representations or warranties about the accuracy, completeness
> or reliability of any information contained in this publication. The State
> of Queensland disclaims all responsibility and all liability (including
> without limitation for liability in negligence) for all expenses, losses,
> damages and costs you might incur as a result of the information being
> inaccurate or incomplete in any way, and for any reason reliance was placed
> on such information.
>



-- 
-------------------------------------------
Craig Taylor
ctalkobt@ctalkobt.net

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message