airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chathuri Wimalasena <kamalas...@gmail.com>
Subject Re: Airavata 0.16 maven module organization
Date Tue, 02 Jun 2015 17:21:08 GMT
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> 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