Hi Adrian, I've been discovered :) I enjoyed exploring a ESB scenario. In abstract you may go along the lines of any of ESB solutions this way:
1) Any task is performed by suitably configured components 2) componets live in a container 3) components communicate through a message router 4) special components resolve technology itegration issues (connectors) Another interesting approach is provided by Akka. Have a look to this thread https://groups.google.com/forum/#!topic/akka-user/KFzPbaNglPQ A clojure library providing erlang like actors is pulsar https://github.com/puniverse/pulsar Cheers, Luca Il giorno mercoledì 12 febbraio 2014 13:37:28 UTC+1, Adrian Mowat ha scritto: > > Hi Luca > > Thanks for the links! > > I definitely have a lot of hammock time ahead of me :-) > > Cheers > > Adrian > > > On 11 Feb 2014, at 14:37, icamts wrote: > > Hi Adrian, > the answer is more off-topic than the question :) but have a look to > Spagic (I'm a member of the developers' team), Mule ESB, Petals ESB or > Talend ESB. You may already know Talend as an ETL solution. You'll find > tools to define, configure and run instances of services or processes. > Monitong application with re-start / re-run facilities. Connectors for > services / processes integration. > > In a ESB scenario developers will design simple processes with a quartz or > file polling connector followed by a script / custom component designed to > accomplist the batch task. > > Custom components can be written in clojure if you reify the required > interface. The only cavevat is the AOT compilation. > > Some other ideas are below, along your problem statement. > > Cheers, > Luca > > >> - Be controlled by artifacts developers control >> - Probably be github friendly >> >> > Put service deployment directory and estensions / plugins directory under > version control and copy them as a part of the deployment process. An ESB > can be deployed like a simple webapp. > >> >> - >> - Provide a direct relationship between an application and its >> tasks >> >> > Choose meaningful service names. Deploy a local ESB in the same AS of your > application and use an in-memory invoker / connector. > >> >> - Support separate sandbox, staging and production environments >> >> > Use different ESB instances. > >> >> - Be scalable >> >> > Single task scalability is up to your code. > >> >> - Be distributed - jobs for application X can run on the same host as >> application X or on a different host or cluster as needed >> >> > Sevices / processes can be run on every ESB instance. Use in-memory > invoker / connector or soap invoker / connector. > >> >> - Be secure >> >> > Use https for remote connection. Use sftp for file transfer. > >> >> - Be easy to administer >> - Job progress and status is visible >> >> > Service progress notification is up to your code and not a monitor console > feature. Process running step is available. > >> >> - >> - Alert when a job fails >> >> > Use a mail connector to alert on job fails > >> >> - >> - Easy to re-run a job >> >> > Restart / rerun through monitoring console. > >> >> - >> - Easy to spin up new hosts and/or move all processing to a >> different host >> >> > Deploy a new instance with the same configuration. No running service can > be moved. Running processes may be moved. It depends on workflow engine > implementation details. > >> >> - >> - Provide a standard way of organising assets like files and >> configs across all our applications >> >> > (Not sure what you mean.) > >> >> - Comply with our hybrid infrastructure (stuff runs internally and in >> the cloud) >> - Data can move internal -> cloud >> >> > Is it an ETL task? > >> >> - >> - Data can move cloud -> internal >> >> > Same as before > >> >> - >> - Data can be processed entirely within a host >> >> > That's so > >> >> - Support different ways of triggering a job >> - Scheduled tasks >> >> > Use a quartz input connector > >> >> - >> - Run when file x arrives >> >> > Use a file poller input connector > >> >> - >> - Run job y after job x completes >> >> > Use an output connector to trigger the next job start or design a process > with jobs in a sequence. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com <javascript:> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com <javascript:> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/95W4MlkFgnY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+u...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/groups/opt_out. > > > > Adrian Mowat > > Tweet: @mowat27 > > Am I being a bit short? Here's why: http://emailcharter.org/, > http://inboxzero.com/ > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
