airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject Re: Airavata 0.16 maven module organization
Date Tue, 02 Jun 2015 17:35:07 GMT
Hi Chathuri,

What I am proposing is each component (irrespective of whether it is actively called by RPC
or passively picks up from work queue) describe its high level interface through thrift IDL’s.
If the component exposes a thrift interface then the component client is implementing using
these interfaces. But if the component is passive, then there is no server and client but
these IDL’s describe what the component is supposed to do and what it requires. As an example,
validator component interface will be validateExperiment(Experiment experiment), Similarly
the task executor will something like launchProcess(Process process) and so on.

Within the component it is totally upto to component developer to organize it based on implementation
preferences. For instance current GFac will have thrift submitJob outside, but will have current
GFac interface inside. But no other component but GFac will care about what GFac interface
looks like and is implemented. The components should only care about submitJob thrift interface.
We should treat components as silo’s and not have dependencies to one another (beyond clients).


All components have dependencies to airavata common fabric like Registry Catalogs, Messaging,
Suggesting Logging and so on. 

Suresh

> On Jun 2, 2015, at 1:21 PM, Chathuri Wimalasena <kamalasini@gmail.com> wrote:
> 
> Hi Suresh, 
> 
> Why we need component-interface-descriptions (which resides outside) and  interfaces
inside the component ? 
> 
> Thanks..
> Chathuri 
> 
> On Tue, Jun 2, 2015 at 11:25 AM, Suresh Marru <smarru@apache.org <mailto:smarru@apache.org>>
wrote:
> Hi All,
> 
> While we let other thread on leaf modules going, here is a abstract suggestion for maven
modules. Please critique:
> 
> We need to ensure the directory structure used for code navigability should not created
additional maven release artifacts. In 0.15 and earlier versions, we have been releasing these
empty artifacts for no good reason.
> 
> ├── airavata-api
> │   ├── airavata-api-interface-descriptions  (these are the thrift IDL’s)
> │   ├── airavata-data-models (thrift generated data models, used by clients,
components and api server)
> │   ├── airavata-api-java-stubs  (thrift generated java stubs used by clients
as well has servers for implementations)
> │   ├── airavata-api-server (api service handlers and startup classes)
> │   ├── api-security-manager (gsoc project to add API level oauth security)
> ├── clients   (self explanatory client SDK’s - thrift generated code plus samples)
> │   ├── airavata-client-cpp-sdk
> │   ├── airavata-client-java-sdk
> │   ├── airavata-client-php-sdk
> │   ├── airavata-client-python-sdk
> │   ├── airavata-sample-examples
> │   └── airavata-xbaya-gui
> ├── distribution
> ├── integration-tests
> 
> For component organization we can go any number of ways. The fundamental proposition
I have is components are literally loosely coupled and live by themselves.
> 
> One suggestion is to organize all component interface descriptions, services and clients
into and then component implementations (which internally can have interfaces, implementations
of these interfaces, util packages and so forth).
> 
> ├── components
> │   ├── commons
> │   ├── component-interface-descriptions
> │   ├── component-services
> │   │   ├── credential-store-service
> │   │   ├── orchestrator-service
> │   │   ├── task-executor-service
> │   │   └── workflow-interpreter-service
> │   ├── component-clients
> │   │   ├── credential-store-client
> │   │   ├── orchestrator-client
> │   │   ├── task-executor-client
> │   │   ├── workflow-interpreter-client
> │   │   └── messaging
> │   ├── orchestrator-component-impl
> │   │   ├── orchestrator-interface
> │   │   └── orchestrator-impl….
> │   ├── registry
> │   │   ├── app-catalog
> │   │   ├── experiment-catalog
> │   │   └── resource-catalog
> 
> Other suggestion is to organize by a component. Within the component it can also have
the service interfaces and clients.
> 
> This facilitates to have one more then one component implementing the same component
interface. They are used based on usecases and stability. In no scenario we should have one
component implementation depending on other component’s implementation. If there is really
a common functionality we should have a module in commons used by both. At most the component
should only have dependency to component's thrift clients or in case of registry and messaging
appropriate java clients.
> 
> This is again abstract, once we debate on the down sides and address them, we can make
this concrete to cover it all.
> 
> Cheers,
> Suresh
> 
> 
> 
> 
> 
> 
> 
> 


Mime
View raw message