Hi, Jean-Sebastian At a useability level, I think it is also worth looking at JBoss Fuse Service Works, particularly Switchyard. In my opinion, that team nailed SCA. I think there are some valuable concepts there that would work well;who cares what the language or implementation is. JBoss FSW is really good at using SCA to do exactly what you are talking about: Switchyard services refer to each other easily using SCA - external (consumer or producer) references use a multitude of bindings.
A current implementation I am working on totally blows my mind as to how much better it is than classic ESBs. Arved On Mon, Oct 19, 2015 at 3:07 AM, Ole Ersoy <ole.er...@gmail.com> wrote: > Hello Jean-Sebastien, > > You may also want to have a look at [Top 10 Browserling Inventions]( > http://www.catonmat.net/blog/top-10-browserling-inventions/). > > I think you would be interested in the Seaport Service Registry, Ploy, > Airport, Upnode, and Bouncy. > > Cheers, > - Ole > > > On 10/19/2015 12:25 AM, Jean-Sebastien Delfino wrote: > >> Hi all, >> >> It has been a while... >> >> Today I was reflecting on what I've been doing in the last two years, >> mostly micro-services on Node.js, and I'm starting to think that the >> original ideas behind SCA and Tuscany may be useful to me again. So you may >> hear a bit more from me on this list again in the next few weeks... >> >> My new world is very different from the world we initially created >> Tuscany for: Node.js, Javascript everywhere, isomorphic Web apps, simple >> REST 'services', simple middleware and databases, and not much technical >> complexity getting in the way of writing business logic. Many of the issues >> we were trying to address with SCA like multi-language, multi-protocol, >> complexity of the JEE platform and WS stack, weird objects requiring >> injection etc, don't exist anymore in my new world. >> >> That's great as developing Web micro-services has become really easy! So >> easy that I have so many micro-services in my apps now that sometimes it >> gets a bit hard to keep track which service calls which, what's that >> service address, what I need to change when that service moves or gets >> updated, or what's involved when something goes wrong and I need to find >> which service broke. >> >> That's a serious problem, and something that made me think about SCA and >> Tuscany again. Despite all the greatness of Node.js and REST and >> micro-services, I'm probably still missing some kind of assembly model like >> we had with SCA. Something that would model my app as as an assembly of >> micro-services. Something that would allow my services to reference each >> other without having to update environment variables all over the place >> with their addresses. Something that would allow me to understand that a >> service broke because another service that it references is currently down. >> Something that would provide a description of my service call graphs for >> debugging for example. Right now, it's really easy for me to develop >> micro-services and wire them together, but I don't have a good way to model >> that wiring. >> >> Maybe what I'm looking for is a small subset of the original SCA >> concepts: a description of my app as an assembly of services, Javascript >> friendly, simple and lightweight, declarative but programmable, and >> distributed and dynamic as my services need to move around to scale out or >> when a Cloud region goes down. So, I'm going to spend some of my spare time >> on this, evenings and weekends, and try to put together a new variation of >> Tuscany for Node.js. I'd like to figure out if that good old SCA can help >> me again with my little micro-services issues. >> >> I'm thinking about calling that new variation of Tuscany 'Tuscany.js', >> and maybe put it in a new 'js' sub-folder in the Tuscany repo besides the >> existing java and cpp folders. >> >> I'd love to work on it with other folks in the community if they're >> interested! Thoughts? >> >> - Jean-Sebastien >> > >
