I thought I'd bring this thread back to life again :). We've had a few other threads brainstorming and explaining this in the past...
http://camel.465427.n5.nabble.com/implementing-Protocols-or-a-way-to-make-it-easier-to-black-box-routes-and-compose-them-with-other-ros-td3218777.html#a3218777 And Ashwin created the routebox stuff... http://camel.apache.org/routebox.html though after taking a look at the samples and doc it does seem a little complex to my simple brain (that long URI with query arguments to use the route box, those strategy objects etc); I was wondering if there was a simpler way of achieving the same effect for the end user (taking a few routes and turning them into a black box) by reusing more of the existing Camel infrastructure; so end users have as little to learn as possible - using convention over configuration (and avoiding registering strategies in registres and using complex URI parameters etc). In a totally different tangent; I was wondering about using a separate CamelContext and set of routes to test a set of production routes... https://issues.apache.org/jira/browse/CAMEL-3563 then after looking at the RouteBox stuff I wondered about combining these all together into the same (little) idea and small amount of code. First the new idea I had was; rather than having a new Protocol thing we've talked about in the past; or combining together a RouteBuilder and Component and all that jazz; how about if we had something really simple; a new Camel Component which all it does is expose its local endpoints in a CamelContext to other CamelContexts. Thats it really; no new concepts to wrap our heads around - the black box becomes just a separate CamelContext. So you can take a bunch of routes, create a regular CamelContext - using the Java DSL or Spring or whatever - then expose this CamelContext in your registry (Spring / JNDI / Guice / OSGi / whatever). Internally that black box camel context might be using endpoints like "direct:invoices" or "seda:purchaseOrders" and other middleware stuff too. You can then register this CamelContext in your registry as a logical black box to represent your service or protocol using an ID like "supplyChain" or "accounts". Then to use the black box from another CamelContext you can use the simple naming convention of "accounts:invoices" or "supplyChain:purchaseOrders". This is then mapped into the black boxes' CamelContext's local endpoints of "direct:invoices" or "seda:purchaseOrders" etc. i.e. you can use URIs of the form camelContextId:logicalLocalEndpointName Here's a sample test case to show the idea http://svn.apache.org/viewvc/camel/trunk/components/camel-context/src/test/java/org/apache/camel/component/context/JavaDslBlackBoxTest.java?revision=1069442&view=markup the createRegistry() method, creates the black box CamelContext with a local route using "direct:purchaseOrder" and "direct:invoice" - then this is registered in the registry as an "accounts" component (lines 58-70). All run of the mill Camel stuff. Then in the test case itself (in a separate CamelContext) we then create a separate route to test this black box; see the createRouteBuilder() method (line 80). So we send to "accounts:purchaseOrder" and consume from "accounts:invoice". If you are a more verbose kinda guy and want to be absolutely 100% literal rather than use nice simple logical names you could use "context:accounts:direct://invoices" to use the new "context" component to refer explicitly to the "accounts" CamelContext instance then the explicit fully qualified URI "direct://invoices" within that context. e.g. this is a verbose URI test case alternative http://svn.apache.org/viewvc/camel/trunk/components/camel-context/src/test/java/org/apache/camel/component/context/JavaDslBlackBoxWithVerboseUriTest.java?revision=1069442&view=markup I've raised an issue for this new black box idea... https://issues.apache.org/jira/browse/CAMEL-3651 So from the end users perspective; its just routes and CamelContext all the way down; there's just this new little mechanism for treating a CamelContext as a black box (bean) in a registry. I've added some docs on the wiki which maybe give a simpler overview of this idea (without the history of the discussions here) which might be a simpler place to start if you don't mind about the history of this idea and the iterations we've been through... https://cwiki.apache.org/confluence/display/CAMEL/Context Thoughts? -- James ------- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan Blog: http://macstrac.blogspot.com/ Open Source Integration -- James ------- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan Blog: http://macstrac.blogspot.com/ Open Source Integration
