airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <>
Subject Re: Separate Thrift services- Code restructure
Date Thu, 06 Nov 2014 03:52:50 GMT
Thanks Amila for chiming in and you hit it right. I do not think we should disrupt any fault
tolerant architecture. When we discussed the FT, the focus was on single job submissions and
the idea of Orchestrator sprung up as a higher level component to GFac. Following the same
design, Workflow Engine needs to also sit behind Orchestrator. 

The current question though is, should workflow engine be a separate service or have a simple
java API which runs within Orchestrator server. Either way we keep it as a separate service
or bundle it, I do not think it will not hinder andy FT strategies. But good reminder through,
we need to walk through the scenarios and be definite. 


On Nov 5, 2014, at 12:32 PM, Amila Jayasekara <> wrote:

> Swiftly went through this thread. Seems you are going to merge workflow service and orchestrator
(if not ignore my comment).
> I remember we putting lot of thoughts to fault tolerance aspects of Orchestrator and
also workflow interpreter some time back. I do believe merging will effect the FT design we
came up at that time (Hope those design notes are somewhere in the SGG repo) and you may need
to rethink about FT aspects.
> Thanks
> -AJ
> On Thu, Oct 30, 2014 at 11:34 AM, Raminder Singh <> wrote:
> We need to approach merging of Workflow server slightly different. Methods like registerWorflow,
getWorkflow etc need to be part of API server so client like Xbaya need to call them remotely.
I am going to get rid of workflow server and merge methods to Airavata API server and handle
launch in Orchestrator. 
> Thanks
> Raminder
>>> From: Shameera Rathnayaka []
>>> Sent: Tuesday, October 28, 2014 3:56 PM
>>> To: dev
>>> Subject: Re: Separate Thrift services- Code restructure
>>> +1 for merging Workflow service with Orchestrator,
>>> we are not get any advantage by keeping those two as separate services.
>>> Thanks,
>>> Shameera.
>>> On Tue, Oct 28, 2014 at 4:35 PM, Raminderjeet Singh <<>>
>>> I need to move workflow sever/client out out API server to remove extra dependencies
on workflow model. I am going to move workflow server and client to orchestrator server and
can get rid of server part as next step.
>>> Thanks
>>> Raminder
>>> On Tue, Oct 28, 2014 at 3:49 PM, Suresh Marru <<>>
>>> + 1.
>>> I think we can leave out the workflow service and its probably best to embedded
it with orchestrator, since there is so much overlap. So that leaves 3 services:
>>> API Server - Client
>>> Orchestrator Server -Client
>>> GFac Server - Client
>>> Suresh
>>> On Oct 28, 2014, at 3:32 PM, Raminder Singh <<>>
>>>> Hi All,
>>>> I am fixing AIRAVATA-1471 to create separate distributions for all the Thrift
services in Airavata so that we can run all in separate JVMs and dockerize (<>)
the servers. In this exercise, i found we don’t have client stubs for several components
in separate artifacts like Orchestrator Client is part of Orcherstrator Service, GFAC client
is part of Orcherstator-Core, Workflow server and client is part of Airavata API server and
client. To be consistent with API server and reduce maven dependency tree, i am going to create
airavata— <component>—stubs package and add the component client to that project.
I need to move the code and changed dependencies etc. Please let me know if there are any
objections. If not i will go ahead tomorrow and make the change and commit them after testing.
>>>> Thanks
>>>> Raminder
>>> --
>>> Best Regards,
>>> Shameera Rathnayaka.
>>> email: shameera AT<> , shameerainfo AT<>
>>> Blog :

View raw message