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.

Reply via email to