Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of satoshi-k@stratosphere.co.jp
 designates 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA1FB458C@SJCPMAILBOX01.citrite.net>
References: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA1FB458C@SJCPMAILBOX01.citrite.net>
Date: Tue, 20 Nov 2012 12:46:14 +0900
Message-ID: 
 <CAP6bJpAo+=2DAdPDL=EZmSG7CRmfrLuBaiT1f0fwox4-qygC2g@mail.gmail.com>
Subject: Re: [javelin] Updates on javelin...
From: Satoshi Kobayashi <satoshi-k@stratosphere.co.jp>
To: cloudstack-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

2012/11/20 Alex Huang <Alex.Huang@citrix.com>:
> Just like to update everyone on the work on javelin.
>
> We've basically started the work of breaking out components.  Currently we have
>
> Framework - Framework pieces that underlies all services.
>   - ipc: for ipc mechanism
>   - jobs: for jobs management
>
> Engine - Cloud-Engine Service
>   - api: service api
>   - components-api: api for the plugins
>   - compute: compute orchestrations
>   - network: network orchestration
>   - planning: deployment planning orchestrations
>   - schema: VO objects used by all of the components to present a schema.
>   - service: rest service component
>   - storage: storage orchestration
>   - orchestration: overall vm orchestartion
>
> Services - Various services
>   - Nothing is done here yet.  But it's planned to move the api, management, ssvm, consoleproxy, and virtual router in here.
>
> Plugins - plugins.  This directory is unchanged but expect to see more storage plugins being introduced here.
>
> The most work being done here are two parts:
>  - Storage orchestration and provisioning separation
>  - Data center abstraction layer and services.
>
> We've also been looking at jax-rs 399 and apache cxf to implement the rest service part of the cloud-engine.  Let us know if you have any concerns regarding this approach.

It is planning to use jax-rs to implement internal API? Or is it
certain CloudStack API now?

If It is the latter:
I think that it may not necessarily be suitable for implementing Query
API. I think that it just matches if there is a plan to refactor into
RESTful more which throw away backward compatibility. (ex. Resource
structure is made to a layer).

But I have not an alternative idea. This may only be my overanxiety. I
think that I am good, if CloudStack API is refactored.

BTW, what is Javelin branch? It seems a branch for refactoring.

>
> --Alex
>
>