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

Reply via email to