Return-Path: X-Original-To: apmail-airavata-dev-archive@www.apache.org Delivered-To: apmail-airavata-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 07B3518EBC for ; Sun, 31 May 2015 00:36:58 +0000 (UTC) Received: (qmail 35436 invoked by uid 500); 31 May 2015 00:36:57 -0000 Delivered-To: apmail-airavata-dev-archive@airavata.apache.org Received: (qmail 35381 invoked by uid 500); 31 May 2015 00:36:57 -0000 Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@airavata.apache.org Delivered-To: mailing list dev@airavata.apache.org Received: (qmail 35369 invoked by uid 99); 31 May 2015 00:36:57 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 31 May 2015 00:36:57 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 3356DCA09A for ; Sun, 31 May 2015 00:36:57 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.9 X-Spam-Level: *** X-Spam-Status: No, score=3.9 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, KAM_LIVE=1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id mSAE_hotN2wv for ; Sun, 31 May 2015 00:36:50 +0000 (UTC) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id CA4A3204E0 for ; Sun, 31 May 2015 00:36:49 +0000 (UTC) Received: by oiww2 with SMTP id w2so80004902oiw.0 for ; Sat, 30 May 2015 17:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Mg95zVC55HTkFpwr4aKr0apLJIj+8Mrl4Ci1TZy05Xk=; b=QjhOXxpGGCJpt8MYyfvNrMFKkFAofVLCGf/0c2jhEEb3T7bwK8PBQ4LE9ZmcyNlsAi PCyDae5STnf4SeqCcPemY9k0gRtZqWi1bi7SFjAjJwm4Axf5WrkdkxLWokqa0RWsEJAb 5zl6gKrtY6wrYIvMowWBzjlRHjs9TsKV4Cm/kZgGbA+cQ26ZZDLhiERyg5LTjKK2uJpY 8dZ8KJNq3Sh6V1XnJjf8qEo2bMrfiXN51buVDeZlZOABoFBeACTV0Ko8pPDlmGk9zozB QqygGZlG48KrxqLv5bdrKvHVPQ5ToHVethhPpHzDJVk40Od2fkb+VPfYvKypWr49pKwX nWxw== X-Received: by 10.202.230.68 with SMTP id d65mr11968043oih.3.1433032601919; Sat, 30 May 2015 17:36:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.178.198 with HTTP; Sat, 30 May 2015 17:36:21 -0700 (PDT) In-Reply-To: <9C4E5A7E-7A8D-46D3-8ECA-8667D5677C26@apache.org> References: <1EDF3F7A-17FC-4726-B848-D8199D76491F@apache.org> <9C4E5A7E-7A8D-46D3-8ECA-8667D5677C26@apache.org> From: Shameera Rathnayaka Date: Sat, 30 May 2015 20:36:21 -0400 Message-ID: Subject: Re: Too Many Leaf Modules. To: dev Content-Type: multipart/alternative; boundary=001a1141c9b0307931051755e7bf --001a1141c9b0307931051755e7bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Suresh, > > Spark is not the right comparison for this discussion. I have been a spar= k > incubation mentor and have been following the code organization since its > early days. All of the spark components you mentions rely on the core. > =E2=80=8BYes, that is what I highlight , each components doesn't have their= own core modules which has the interfaces. Spark SQL module has core submodule but all interfaces reside in main core module. > Let me step back and ask, what is the problem you are trying to solve? We > sure need to cleanup modules and it is time to re-look at the component > organization. But what do you want to really achieve by combining all the > core into monolithic components. It took an effort to cleanly separate > functionality so they can evolve and can be improved independently. > I am not suggesting to go back to the monolithic core which has all implementations and interfaces bundle with together. What i am saying is have core interfaces all together, this will give us clear module dependency graph. This is something like having one root dependency graph instead of multiple roots. As a developer it is cumbersome and hard to deal with module dependency issues. Having too fine gran core modules introduce wrong dependency graph eventually, and it will prevent us to follow proper design patterns in our code base. If we avoid design patterns, it will require more time to find bugs and maintain. This is what I am trying to resolve. I have first hand experiences with current airavata code. If you see the current module dependency graphs, then you will understand why I am making such noise to resolve this. > So why do we make our repository bulky with modules unless it doesn't > provide any considerable advantage. > > =E2=80=8BIf we really w > =E2=80=8Bant to =E2=80=8B > separate distribution bundle for each component ( apiServer , Orchestrato= r > and Gfac ) let > =E2=80=8B'=E2=80=8B > s use different bin.xml file > =E2=80=8Bs=E2=80=8B > to do it instead of using different modules. But reality is we only use > =E2=80=8Ball in one distribution. > > > Once the monitoring is fixed to use messaging, we really need to decouple > the component deployments. Yes there is a considerable advantage. Each > components has different quality of service requirements. A production > platform has to load balance and scale horizontally. And thats different > for different component. The all in one bundle has 300+ jars, but API > server and orchestrator when independent will have around 50 or so jars. > When I want to deploy api server and orchestrator there is significant > different in small light weight components vs one monolithic core. > > Another problem is component evolution. Lets say there is a production > deployment running 1.1.4 version. Lets say the single job execution is > stable enough and there is a 6 month focused effort on workflow. Say the > master moves to 1.2.8 with all the changes to workflow and only few to > single application execution. We can more comfortably upgrade is they are > cleanly separated modules. But if it is one core and so many changes to i= t > (even though technically they are to different classes, the perception wi= ll > remain), the upgrades will get behind. > > Bottom line I am + 1 for cleaning up the modules. Past few years we have > been moving towards micro service architectures and your suggestions will > reverse this back to monolithic architecture. I am -1 for this change in > direction. > By looking at your miniature component suggestion above, it has 30+ modules. Do you think we really need this number of categorization? With my industrial experience, I have seen =E2=80=8Bnumber of modules in a project always increase with time. Hence=E2= =80=8B If we start 30+ we will come to 40+ and then 50+ =E2=80=8B and so on so forth=E2=80=8B . Why we make this complicated? =E2=80=8BThanks, Shameera.=E2=80=8B > > Suresh > > > =E2=80=8B=E2=80=8BThanks, > =E2=80=8BShameera. > =E2=80=8B > >> >> Suresh >> >> On May 29, 2015, at 11:29 AM, Suresh Marru wrote: >> >> + 1. >> >> I was planning to bring up this issue also. Probably it will not address >> what you are raising, but here is a tree output from airavata labs code = I >> was toying with locally. I did not yet compare it with what you proposed= , I >> will do so later today. >> >> =E2=94=9C=E2=94=80=E2=94=80 airavata-api >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 airavata-api-interface-descripti= ons >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 airavata-api-java-stubs >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 airavata-api-server >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 airavata-data-models >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 api-security-manager >> =E2=94=9C=E2=94=80=E2=94=80 clients >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 airavata-client-cpp-sdk >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 airavata-client-java-sdk >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 airavata-client-php-sdk >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 airavata-client-python-sdk >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 airavata-sample-examples >> =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 airavata-xbaya-gui >> =E2=94=9C=E2=94=80=E2=94=80 components >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 commons >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 component-interface-descriptions >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 component-services >> =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 credential-store-ser= vice >> =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 orchestrator-service >> =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 task-executor-servic= e >> =E2=94=82 =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 workflow-interpreter= -service >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 component-clients >> =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 credential-store-cli= ent >> =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 orchestrator-client >> =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 task-executor-client >> =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 workflow-interpreter= -client >> =E2=94=82 =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 messaging >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 task-adaptors >> =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 compute >> =E2=94=82 =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 data-movement >> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 registry >> =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 app-catalog >> =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 experiment-catalog >> =E2=94=82 =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 resource-catalog >> =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 workflow-interpreter >> =E2=94=9C=E2=94=80=E2=94=80 distribution >> =E2=94=9C=E2=94=80=E2=94=80 integration-tests >> >> >> >> On May 29, 2015, at 10:15 AM, Shameera Rathnayaka >> wrote: >> >> Hi Devs, >> >> As we are using different modules to package different type of >> functionalities, which will help us to maintain loosely couple codes. No= w >> the project has 49 leaf module ( one to hit half century :) ). If we all= ow >> project to grow this way, having too fine grain modules will be huge >> headache in future. IMO we should clean this ASAP before it become reall= y >> mess. Actually we half way there, I experienced cyclic dependency issues >> when I was writing workflow implementation and email monitoring. Please = see >> the modules in current repo below. >> >> ( ) >> >> modules ( 43 ) >> app-catalog ( 2 ) >> commons ( 1 ) >> configurations ( 2 ) >> credential-store ( 3 ) >> distribution ( 8 ) >> gfac ( 10 ) >> integration test ( 1 ) >> messaging ( 2 ) >> orchestrator ( 3 ) >> registry ( 3 ) >> security ( 1 ) >> server ( 1 ) >> test-suit ( 1 ) >> workflow ( 1 ) >> workflow-modal ( 3 ) >> xbaya ( 1 ) >> airavata-api ( 5 ) >> tools ( 1 ) >> >> Most of the current modules have interfaces and implementations together= , >> but this violate our main goal which reduce inter module dependencies. >> Following is what I am suggesting, WDYS? >> >> core { has all core interfaces and basic classes of gfac-core , >> orchestrator-core , message-core , monitor core, registry core, >> workflow-core} >> service - all thrift services and service handlers >> orchestrator - orchestrator specific classes >> gfac >> SSH >> BES >> Local >> message - amqp implemention >> distribution >> XBaya >> server - { use different mode input to start server as orchestrator >> , Gfac or/and api-server } >> commons >> registry >> app-catalog >> security >> Workflow >> XBaya-gui >> Integration-test >> >> Thanks, >> Shameera. >> >> >> >> > > > -- > Best Regards, > Shameera Rathnayaka. > > email: shameera AT apache.org , shameerainfo AT gmail.com > Blog : http://shameerarathnayaka.blogspot.com/ > > > --=20 Best Regards, Shameera Rathnayaka. email: shameera AT apache.org , shameerainfo AT gmail.com Blog : http://shameerarathnayaka.blogspot.com/ --001a1141c9b0307931051755e7bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi = Suresh,=C2=A0

Spark is not the right comparison for t= his discussion. I have been a spark incubation mentor and have been followi= ng the code organization since its early days. All of the spark components = you mentions rely on the core.=C2=A0
=E2=80=8BYes, that is what I highlight , each components doesn't= have their own core modules which has the interfaces. Spark SQL module has= core submodule but all interfaces reside in main core module.
<= div>

Let me step back and ask, what is the problem you are= trying to solve? We sure need to cleanup modules and it is time to re-look= at the component organization. But what do you want to really achieve by c= ombining all the core into monolithic components. It took an effort to clea= nly separate functionality so they can evolve and can be improved independe= ntly.=C2=A0


I am not suggesting to go back to the monol= ithic core which has all implementations and interfaces bundle with togethe= r. What i am saying is have core interfaces all together, this will give us= clear module dependency graph. This is something like having one root depe= ndency graph instead of multiple roots. As a developer it is cumbersome and= hard to deal with module dependency issues. Having too fine gran core modu= les introduce wrong dependency graph eventually, and it will prevent us to = follow proper design patterns in our code base. If we avoid design patterns= , it will require more time to find bugs and maintain. This is what I am tr= ying to resolve. I have first hand experiences with current airavata code. = If you see the current module dependency graphs, then you will understand w= hy I am making such noise to resolve this.


So why do we= make our repository bulky with modules unless it doesn't provide any c= onsiderable advantage.=C2=A0
=E2=80=8BIf we really w
=E2=80=8Bant to =E2=80=8B
separat= e distribution bundle for each component ( apiServer , Orchestrator and Gfa= c ) let
=E2=80=8B'=E2=80= =8B
s use different bin.xml file
=E2=80=8Bs=E2=80=8B
=C2=A0to do it instead of usi= ng different modules. But reality is we only use =E2=80=8Ball in one distri= bution.

Onc= e the monitoring is fixed to use messaging, we really need to decouple the = component deployments. Yes there is a considerable advantage. Each componen= ts has different quality of service requirements. A production platform has= to load balance and scale horizontally. And thats different for different = component. The all in one bundle has 300+ jars, but API server and orchestr= ator when independent will have around 50 or so jars. When I want to deploy= api server and orchestrator there is significant different in small light = weight components vs one monolithic core.=C2=A0

Another problem is component evolution. Lets say there is a production d= eployment running 1.1.4 version. Lets say the single job execution is stabl= e enough and there is a 6 month focused effort on workflow. Say the master = moves to 1.2.8 with all the changes to workflow and only few to single appl= ication execution. We can more comfortably upgrade is they are cleanly sepa= rated modules. But if it is one core and so many changes to it (even though= technically they are to different classes, the perception will remain), th= e upgrades will get behind.

Bottom line I am = + 1 for cleaning up the modules. Past few years we have been moving towards= micro service architectures and your suggestions will reverse this back to= monolithic architecture. I am -1 for this change in direction.=C2=A0
=


By lookin= g at your miniature component suggestion above, it has 30+ modules. Do you = think we really need this number of categorization? With my industrial expe= rience, I have seen
=E2=80=8Bnumber of modules in a project always increase with= time. Hence=E2=80=8B
=C2=A0If we start 30+ we will come to 40+ and th= en 50+
=E2=80=8B and so on so forth=E2=80=8B
.=C2=A0 Why we make this compli= cated?=C2=A0

=E2=80=8BThanks,
Shameera.=E2=80=8B

=C2=A0

Suresh


=
=E2=80=8B=E2=80=8BThanks,
=E2=80=8BShameera.
=E2=80=8B

Suresh

On May 29, = 2015, at 11:29 AM, Suresh Marru <smarru@apache.org> wrote:

+ 1.=C2=A0

I was planning to b= ring up this issue also. Probably it will not address what you are raising,= but here is a tree output from airavata labs code I was toying with locall= y. I did not yet compare it with what you proposed, I will do so later toda= y.

=E2=94=9C=E2=94=80=E2=94=80 airavata-api
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 airavata-api-interface= -descriptions
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 airava= ta-api-java-stubs
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 ai= ravata-api-server
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 ai= ravata-data-models
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 a= pi-security-manager
=E2=94=9C=E2=94=80=E2=94=80 clients
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 airavata-client-cpp-sdk
=
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 airavata-client-java-sdk<= /div>
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 airavata-client-php-= sdk
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 airavata-client-= python-sdk
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 airavata-= sample-examples
=E2=94=82 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 aira= vata-xbaya-gui
=E2=94=9C=E2=94=80=E2=94=80 components
= =E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 commons
=E2=94=82 = =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 component-interface-descriptions
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 component-services
=E2=94=82 =C2=A0 =E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 credential-= store-service
=E2=94=82 =C2=A0 =E2=94=82 =C2=A0 =E2=94=9C=E2= =94=80=E2=94=80 orchestrator-service
=E2=94=82 =C2=A0 =E2=94=82 = =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 task-executor-service
=E2=94= =82 =C2=A0 =E2=94=82 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 workflow-interprete= r-service
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 comp= onent-clients
=E2=94=82 =C2=A0 =E2=94=82 =C2=A0 =E2=94=9C=E2=94= =80=E2=94=80 credential-store-client
=E2=94=82 =C2=A0 =E2=94= =82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 orchestrator-client
=E2=94= =82 =C2=A0 =E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 task-executor-clien= t
=E2=94=82 =C2=A0 =E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 w= orkflow-interpreter-client
=E2=94=82 =C2=A0 =E2=94=82 =C2=A0 =E2= =94=94=E2=94=80=E2=94=80 messaging
=E2=94=82 =C2=A0 =E2=94= =9C=E2=94=80=E2=94=80 task-adaptors
=E2=94=82 =C2=A0 =E2=94= =82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 compute
=E2=94=82 =C2=A0 = =E2=94=82 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 data-movement
=
=E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 registry
=E2=94= =82 =C2=A0 =E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 app-catalog
=E2=94=82 =C2=A0 =E2=94=82 =C2=A0 =E2=94=9C=E2=94=80=E2=94=80 experiment= -catalog
=E2=94=82 =C2=A0 =E2=94=82 =C2=A0 =E2=94=94=E2=94=80=E2= =94=80 resource-catalog
=E2=94=82 =C2=A0 =E2=94=94=E2=94=80= =E2=94=80 workflow-interpreter
=E2=94=9C=E2=94=80=E2=94=80 distri= bution
=E2=94=9C=E2=94=80=E2=94=80 integration-tests
<= div>


O= n May 29, 2015, at 10:15 AM, Shameera Rathnayaka <shameera@apache.org> wrote:
=
Hi Devs,=C2=A0

A= s we are using different modules to package different type of functionaliti= es, which will help us to maintain loosely couple codes. Now the project ha= s 49 leaf module ( one to hit half century :) ). If we allow project to gro= w this way, having too fine grain modules will be huge headache in future. = IMO we should clean this ASAP before it become really mess. Actually we hal= f way there, I experienced cyclic dependency issues when I was writing work= flow implementation and email monitoring. Please see the modules in current= repo below.=C2=A0

<module-name> ( <num of child modules> )

modules =C2=A0( 43 )
=C2=A0 =C2=A0 =C2=A0app-catalog ( 2 )<= /div>
=C2=A0 =C2=A0 =C2=A0commons ( 1 )
=C2=A0 =C2=A0 =C2=A0c= onfigurations ( 2 )
=C2=A0 =C2=A0 =C2=A0credential-store ( 3 )
=C2=A0 =C2=A0 =C2=A0distribution ( 8 )
=C2=A0 =C2=A0 =C2= =A0gfac ( 10 )
=C2=A0 =C2=A0 =C2=A0integration test ( 1 )
=C2=A0 =C2=A0 =C2=A0messaging ( 2 )
=C2=A0 =C2=A0 =C2=A0orches= trator ( 3 )
=C2=A0 =C2=A0 =C2=A0registry ( 3 )
=C2=A0 = =C2=A0 =C2=A0security ( 1 )
=C2=A0 =C2=A0 =C2=A0server ( 1 )
=C2=A0 =C2=A0 =C2=A0test-suit ( 1 )
=C2=A0 =C2=A0 =C2=A0wor= kflow ( 1 )
=C2=A0 =C2=A0 =C2=A0workflow-modal ( 3 )
= =C2=A0 =C2=A0 =C2=A0xbaya ( 1 )=C2=A0
airavata-api ( 5 )
tools ( 1 )=C2=A0

Most of the current modules ha= ve interfaces and implementations together, but this violate our main goal = which reduce inter module dependencies. Following is what I am suggesting, = WDYS?

core { has all core interfaces and basic cla= sses of gfac-core , orchestrator-core , message-core , monitor core, regist= ry core, workflow-core}
service - all thrift services and service= handlers=C2=A0
orchestrator - orchestrator specific classes
gfac=C2=A0
=C2=A0 =C2=A0 =C2=A0SSH =C2=A0
=C2=A0 = =C2=A0 =C2=A0BES
=C2=A0 =C2=A0 =C2=A0Local
message - am= qp implemention=C2=A0
distribution=C2=A0
=C2=A0 =C2=A0 = =C2=A0XBaya
=C2=A0 =C2=A0 =C2=A0server - { use different mode inp= ut to start server as orchestrator , Gfac or/and api-server }
com= mons
registry
app-catalog
security
= Workflow
XBaya-gui
Integration-test=C2=A0
Thanks,=C2=A0
Shameera.





= --=C2=A0
Best Regards,
Shameera Rathnayaka.<= /span>

ema= il: shameera AT=C2=A0apache.org=C2=A0, shameerainfo AT=C2=A0gmail.com
Blog :=C2=A0http://shameerarathnay= aka.blogspot.com/



=
--
Best Regards,
Sha= meera Rathnayaka.

email: shameera AT apache.org , shameerainfo AT gmail.com
Blog : htt= p://shameerarathnayaka.blogspot.com/
--001a1141c9b0307931051755e7bf--