You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Craig Taylor <ct...@ctalkobt.net> on 2017/12/05 02:47:25 UTC

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 <ef...@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

RE: Need advice on application architecture with camel

Posted by Matthew Shaw <Ma...@ambulance.qld.gov.au>.
Lol - no worries.

Matthew Shaw
Lead Solutions Architect
HRIS Program Integration
Work: 36353103


-----Original Message-----
From: Craig Taylor [mailto:ctalkobt@ctalkobt.net] 
Sent: Tuesday, 5 December 2017 1:03 PM
To: users <us...@camel.apache.org>
Subject: Re: Need advice on application architecture with camel

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 <us...@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 <ef...@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.htm
> > l 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
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.

Re: Need advice on application architecture with camel

Posted by Craig Taylor <ct...@ctalkobt.net>.
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 <us...@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 <ef...@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

RE: Need advice on application architecture with camel

Posted by Matthew Shaw <Ma...@ambulance.qld.gov.au>.
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 <us...@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 <ef...@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.