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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 >>>>> >>>> >>>> >>> >> >
