incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <>
Subject [DISCUSS] Refactoring ways for components to interact
Date Tue, 04 Dec 2012 01:38:05 GMT
This is a follow up email on the topic I posted before, I've already put
in a skeleton implementation for things I mentioned in this discussion
email.  I'd like to update the community about one of the coding flavors
that are supported in this implementation at RPC layer. Please feel free
to comment.

If you are using RPC as a client only,  assuming you already have wired a
RPC provider, these are some examples to use it

1) Async RPC call 

StartVMCommand cmd = new StartVMcommand();
rpcProvider.newCall( <your target component endpoint
.addCallbackListener(new RpcCallbackListener<StartVMAnswer>() {

public void onSuccess(StartVMAnswer anser)  {

public void onFailure(RpcException e) {


2) Sync RPC call

StartVMCommand cmd = new StartVMcommand();
RpcClientCall call = rpcProvider.newCall( <your target component endpoint
Try {
StartVMAnswer answer = call.get();
} catch (RpcTimeoutException e) {
} catch( RpcIOException e) {
}  catch(RpcException e) {

If you are writing a service RPC component, have a class that participates
the RPC framework by extending ComponentEndpoint class, ComponentEndpoint
also allows you to participate event bus signaling with annotations

public MyServiceEndpoint extends ComponentEndpoint  {

void HandleStartVM(final RpcServerCall call) {

Final StartVM cmd = call.getCommandArg();
_executor.execute(new Runnable() {
public void run() {
StartVMAnswer answer;

void onPrepareNetwork(String sender, String topic, Object args) {

There are other supported ways in the skeleton framework as well, for
example, one way RPC or event-dispatching based style,  but it seems so
far the above style is what  most people prefers.


On 11/13/12 6:20 PM, "Kelven Yang" <> wrote:

>I'm now working on some generic architecture-refactoring work, I'd like to
>share what I'm doing, your comments and feedbacks are very welcome
>Currently there are two major types of components that have
>inter-component interaction beyond Java method-call-bindings, one is
>Resource and the other one is what we called managers. Resources usually
>residents within their tenant environment(agent at client side or
>management server itself at server side), and managers run directly inside
>management server. Resources and managers communicate each other by
>exchanging Commands and Answers.
>For rest of other modules (for example, so called
>plugins/Gurus/Elements/Adapters), they usually bind to corresponding
>managers through normal Java method-calls.
>From high level perspective, the architecture looks relatively clean,
>however, as we add more and more features, things start to become murky,
>the major issue of this architectures is that we are lack of a clear
>middle layer for various components to build up interactions, so we end up
>with things like, a network component might need to wire agent manager in
>order to communicate with a particular agent. And agent manager itself, in
>addition to provide a communication layer, it has baked in a lot of
>CloudStack business logic to define what a agent should behave like (i.e.,
>StartupCommand/RoutingStartupCommand, etc).
>I'll start to work on following things to make CloudStack reshape into
>multi-layered architecture, focusing on providing a uniformed grand for
>components to interactive with each other and give all components
>first-class citizenship within CloudStack system
>1) a low-level messaging layer
>This layer provides three major functions
>	- endpoint address space that across management servers (clustering will
>be embedded solely within this layer and be transparent to high level
>	- generic message delivery, Yes, just plain arbitrary message delivery
>	- protocol multiplexing, allow applications on top of
>2) Event bus for component signaling
>	A multiplexed layer on top of messaging layer, it provides
>publisher/subscriber pattern within management server node, cross
>management server nodes to provide light-weight signaling mechanism
>between components
>3) RPC/Async RPC layer
>	- A multiplexed layer on top of messaging layer, although components are
>free to use any other RPC mechanism, however, within CloudStack internal,
>this generic RPC/Async RPC facility may probably be used the most.
>	- sequence control
>4) Event dispatching mechanism for Async orchestration

View raw message