You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@gmail.com> on 2015/10/19 07:25:57 UTC
[DISCUSS] Tuscany.js - an assembly model for Node.js micro-services
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
unsubscribe
Posted by John LaFata <su...@isynergetics.com>.
unsubscribe
Re: [DISCUSS] Tuscany.js - an assembly model for Node.js micro-services
Posted by Jean-Sebastien Delfino <js...@gmail.com>.
> Superagent is a pretty impressive node REST client, in case you wanted to
experiment.
Yes, Superagent is very nice. I've also been using Request [1] ... works
really well!
[1] https://www.npmjs.com/package/request
- Jean-Sebastien
On Wed, Oct 21, 2015 at 8:36 AM, Ole Ersoy <ol...@gmail.com> wrote:
> Hi Jean-Sebastian,
>
> Honestly I have not had a chance to play with Seaport yet (Hope to get to
> it soon). Someone else also asked about maintenance here:
> https://github.com/substack/seaport/issues/72
>
> Looks like he's still waiting on a response. I imagine you could take a
> REST HATEOAS approach to WRT communicating what services are related to /
> referenced by a particular service:
> https://spring.io/understanding/HATEOAS
>
> Superagent is a pretty impressive node REST client, in case you wanted to
> experiment. I'm also working on a Maven like build system for Node called
> VerdiJS.
> https://github.com/verdijs
>
> It will use self contained modularized Gulp based tasks for compiling ES6,
> Coffescript, etc. like this one:
> https://github.com/verdijs/verdijs-task-clean
>
> And utilize the same type of standard directory structure that Maven uses.
> https://github.com/verdijs/verdijs-pli
>
> Cheers,
> - Ole
>
>
>
>
>
>
> On 10/21/2015 01:00 AM, Jean-Sebastien Delfino wrote:
>
> Hi Ole,
>
> Seaport looks nice and could maybe become part of a Node-friendly
> solution. It looks like a registry like many other registries out there
> allowing me to lookup a service name@version and get its host:port, but
> pretty light weight.
>
> Do you know if Seaport would also allow me to store the fact that a
> service X references service Y? (as that's really what I'm looking for with
> SCA references bound to services, locating service Y is only a small part
> of the story...)
>
> Also is Seaport still actively maintained?
>
> Thanks!
>
> - Jean-Sebastien
>
> On Sun, Oct 18, 2015 at 11:07 PM, Ole Ersoy <ol...@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
>>>
>>
>>
>
>
Re: [DISCUSS] Tuscany.js - an assembly model for Node.js
micro-services
Posted by Ole Ersoy <ol...@gmail.com>.
Hi Jean-Sebastian,
Honestly I have not had a chance to play with Seaport yet (Hope to get to it soon). Someone else also asked about maintenance here:
https://github.com/substack/seaport/issues/72
Looks like he's still waiting on a response. I imagine you could take a REST HATEOAS approach to WRT communicating what services are related to / referenced by a particular service:
https://spring.io/understanding/HATEOAS
Superagent is a pretty impressive node REST client, in case you wanted to experiment. I'm also working on a Maven like build system for Node called VerdiJS.
https://github.com/verdijs
It will use self contained modularized Gulp based tasks for compiling ES6, Coffescript, etc. like this one:
https://github.com/verdijs/verdijs-task-clean
And utilize the same type of standard directory structure that Maven uses.
https://github.com/verdijs/verdijs-pli
Cheers,
- Ole
On 10/21/2015 01:00 AM, Jean-Sebastien Delfino wrote:
> Hi Ole,
>
> Seaport looks nice and could maybe become part of a Node-friendly solution. It looks like a registry like many other registries out there allowing me to lookup a service name@version and get its host:port, but pretty light weight.
>
> Do you know if Seaport would also allow me to store the fact that a service X references service Y? (as that's really what I'm looking for with SCA references bound to services, locating service Y is only a small part of the story...)
>
> Also is Seaport still actively maintained?
>
> Thanks!
>
> - Jean-Sebastien
>
> On Sun, Oct 18, 2015 at 11:07 PM, Ole Ersoy <ole.ersoy@gmail.com <ma...@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
>
>
>
Re: [DISCUSS] Tuscany.js - an assembly model for Node.js micro-services
Posted by Jean-Sebastien Delfino <js...@gmail.com>.
Hi Ole,
Seaport looks nice and could maybe become part of a Node-friendly solution.
It looks like a registry like many other registries out there allowing me
to lookup a service name@version and get its host:port, but pretty light
weight.
Do you know if Seaport would also allow me to store the fact that a service
X references service Y? (as that's really what I'm looking for with SCA
references bound to services, locating service Y is only a small part of
the story...)
Also is Seaport still actively maintained?
Thanks!
- Jean-Sebastien
On Sun, Oct 18, 2015 at 11:07 PM, Ole Ersoy <ol...@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
>>
>
>
Re: [DISCUSS] Tuscany.js - an assembly model for Node.js micro-services
Posted by Jean-Sebastien Delfino <js...@gmail.com>.
Hi Arved,
OK that makes sense :) I'll take another look at Switchyard. Thanks!
- Jean-Sebastien
On Sat, Oct 24, 2015 at 5:19 AM, Arved Sandstrom <ah...@gmail.com> wrote:
> Hi, Jean-Sebastien
>
> I wasn't suggesting that you actually use JBoss EAP + Fuse Service Works.
> :-) It's relatively heavyweight, and let's face it, if you use that you're
> talking Java. But it does have - in my opinion - a very good architecture
> and tooling. At work, I have been able to deliver robust services at a much
> more rapid rate with Switchyard than with anything like Mule, OSB or WMB.
> My idea was simply that anything that gets set up for a Tuscany.js - which
> I'd like to see - would have the same qualities.
>
> On Wed, Oct 21, 2015 at 3:23 AM, Jean-Sebastien Delfino <
> jsdelfino@gmail.com> wrote:
>
>> Hi Arved,
>>
>> I had looked at Switchyard long time ago and yes, it looked nice. I care
>> about the language though as all the services I'm working on are
>> implemented on Node.js. I've now been doing Node.js for several years and
>> just having to spell Java again in this email gives me the chills :)
>>
>> I'm looking for a really lightweight implementation that I could just
>> embed in my Node apps. To put this in perspective, Node itself is a 12Mb
>> download and all of my micro-services and their dependencies are about 3
>> Mb, compared to a total of 390Mb download just for Java + JBoss EAP +
>> Switchyard.
>>
>> I looked through their docs again but can't find much about Javascript
>> other than a reference to JSR223... Have you seen anything about a Node.js
>> integration in there?
>>
>> - Jean-Sebastien
>>
>> On Tue, Oct 20, 2015 at 4:01 PM, Arved Sandstrom <ah...@gmail.com>
>> wrote:
>>
>>> 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 <ol...@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
>>>>>
>>>>
>>>>
>>>
>>
>
Re: [DISCUSS] Tuscany.js - an assembly model for Node.js micro-services
Posted by Arved Sandstrom <ah...@gmail.com>.
Hi, Jean-Sebastien
I wasn't suggesting that you actually use JBoss EAP + Fuse Service Works.
:-) It's relatively heavyweight, and let's face it, if you use that you're
talking Java. But it does have - in my opinion - a very good architecture
and tooling. At work, I have been able to deliver robust services at a much
more rapid rate with Switchyard than with anything like Mule, OSB or WMB.
My idea was simply that anything that gets set up for a Tuscany.js - which
I'd like to see - would have the same qualities.
On Wed, Oct 21, 2015 at 3:23 AM, Jean-Sebastien Delfino <jsdelfino@gmail.com
> wrote:
> Hi Arved,
>
> I had looked at Switchyard long time ago and yes, it looked nice. I care
> about the language though as all the services I'm working on are
> implemented on Node.js. I've now been doing Node.js for several years and
> just having to spell Java again in this email gives me the chills :)
>
> I'm looking for a really lightweight implementation that I could just
> embed in my Node apps. To put this in perspective, Node itself is a 12Mb
> download and all of my micro-services and their dependencies are about 3
> Mb, compared to a total of 390Mb download just for Java + JBoss EAP +
> Switchyard.
>
> I looked through their docs again but can't find much about Javascript
> other than a reference to JSR223... Have you seen anything about a Node.js
> integration in there?
>
> - Jean-Sebastien
>
> On Tue, Oct 20, 2015 at 4:01 PM, Arved Sandstrom <ah...@gmail.com>
> wrote:
>
>> 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 <ol...@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
>>>>
>>>
>>>
>>
>
Re: [DISCUSS] Tuscany.js - an assembly model for Node.js micro-services
Posted by Jean-Sebastien Delfino <js...@gmail.com>.
Hi Arved,
I had looked at Switchyard long time ago and yes, it looked nice. I care
about the language though as all the services I'm working on are
implemented on Node.js. I've now been doing Node.js for several years and
just having to spell Java again in this email gives me the chills :)
I'm looking for a really lightweight implementation that I could just embed
in my Node apps. To put this in perspective, Node itself is a 12Mb download
and all of my micro-services and their dependencies are about 3 Mb,
compared to a total of 390Mb download just for Java + JBoss EAP +
Switchyard.
I looked through their docs again but can't find much about Javascript
other than a reference to JSR223... Have you seen anything about a Node.js
integration in there?
- Jean-Sebastien
On Tue, Oct 20, 2015 at 4:01 PM, Arved Sandstrom <ah...@gmail.com> wrote:
> 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 <ol...@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
>>>
>>
>>
>
Re: [DISCUSS] Tuscany.js - an assembly model for Node.js micro-services
Posted by Arved Sandstrom <ah...@gmail.com>.
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 <ol...@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
>>
>
>
Re: [DISCUSS] Tuscany.js - an assembly model for Node.js
micro-services
Posted by Ole Ersoy <ol...@gmail.com>.
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
Re: [DISCUSS] Tuscany.js - an assembly model for Node.js micro-services
Posted by Luciano Resende <lu...@gmail.com>.
Repo has just been created at :
https://git-wip-us.apache.org/repos/asf/tuscany-js.git
Let's wait couple hours to see when it shows up in github.
On Mon, Oct 26, 2015 at 7:19 AM, Luciano Resende <lu...@gmail.com>
wrote:
> They will be available in github as well.
>
>
> On Sunday, October 25, 2015, Jean-Sebastien Delfino <js...@gmail.com>
> wrote:
>
>> Thanks Luciano!
>>
>> Do you know if new git repositories get automatically mirrored to Github
>> as well, or do we need to create a separate JIRA issue for that?
>>
>> Thanks!
>>
>> - Jean-Sebastien
>>
>> On Sat, Oct 24, 2015 at 7:57 AM, Luciano Resende <lu...@gmail.com>
>> wrote:
>>
>>> An exciting +1 for all that has been said on this thread.
>>>
>>> And btw, I went ahead and requested a new git repository for this
>>> https://issues.apache.org/jira/browse/INFRA-10659
>>>
>>> On Sun, Oct 18, 2015 at 10:25 PM, Jean-Sebastien Delfino <
>>> jsdelfino@gmail.com> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Luciano Resende
>>> http://people.apache.org/~lresende
>>> http://twitter.com/lresende1975
>>> http://lresende.blogspot.com/
>>>
>>
>>
>
> --
> Sent from my Mobile device
>
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: [DISCUSS] Tuscany.js - an assembly model for Node.js micro-services
Posted by Luciano Resende <lu...@gmail.com>.
They will be available in github as well.
On Sunday, October 25, 2015, Jean-Sebastien Delfino <js...@gmail.com>
wrote:
> Thanks Luciano!
>
> Do you know if new git repositories get automatically mirrored to Github
> as well, or do we need to create a separate JIRA issue for that?
>
> Thanks!
>
> - Jean-Sebastien
>
> On Sat, Oct 24, 2015 at 7:57 AM, Luciano Resende <luckbr1975@gmail.com
> <javascript:_e(%7B%7D,'cvml','luckbr1975@gmail.com');>> wrote:
>
>> An exciting +1 for all that has been said on this thread.
>>
>> And btw, I went ahead and requested a new git repository for this
>> https://issues.apache.org/jira/browse/INFRA-10659
>>
>> On Sun, Oct 18, 2015 at 10:25 PM, Jean-Sebastien Delfino <
>> jsdelfino@gmail.com <javascript:_e(%7B%7D,'cvml','jsdelfino@gmail.com');>
>> > 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
>>>
>>
>>
>>
>> --
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>>
>
>
--
Sent from my Mobile device
Re: [DISCUSS] Tuscany.js - an assembly model for Node.js micro-services
Posted by Jean-Sebastien Delfino <js...@gmail.com>.
Thanks Luciano!
Do you know if new git repositories get automatically mirrored to Github as
well, or do we need to create a separate JIRA issue for that?
Thanks!
- Jean-Sebastien
On Sat, Oct 24, 2015 at 7:57 AM, Luciano Resende <lu...@gmail.com>
wrote:
> An exciting +1 for all that has been said on this thread.
>
> And btw, I went ahead and requested a new git repository for this
> https://issues.apache.org/jira/browse/INFRA-10659
>
> On Sun, Oct 18, 2015 at 10:25 PM, Jean-Sebastien Delfino <
> jsdelfino@gmail.com> 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
>>
>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: [DISCUSS] Tuscany.js - an assembly model for Node.js micro-services
Posted by Luciano Resende <lu...@gmail.com>.
An exciting +1 for all that has been said on this thread.
And btw, I went ahead and requested a new git repository for this
https://issues.apache.org/jira/browse/INFRA-10659
On Sun, Oct 18, 2015 at 10:25 PM, Jean-Sebastien Delfino <
jsdelfino@gmail.com> 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
>
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/