[DISCUSS] Refactoring ways for components to interact

[Kelven Yang <ke...@citrix.com>]

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
components)
	- 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

Kelven

[DISCUSS] Refactoring ways for components to interact

[Kelven Yang <ke...@citrix.com>]

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
address>).setCommand("StartVM").setComandArg(cmd).setTimeout(10000)
.addCallbackListener(new RpcCallbackListener<StartVMAnswer>() {

public void onSuccess(StartVMAnswer anser)  {
  Š.
}

public void onFailure(RpcException e) {
Š
} 

}).apply();

2) Sync RPC call

StartVMCommand cmd = new StartVMcommand();
Š
RpcClientCall call = rpcProvider.newCall( <your target component endpoint
address>).setCommand("StartVM").setComandArg(cmd).setTimeout(10000).apply()
;
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  {

@RpcServiceHandler(command="StartVM")
void HandleStartVM(final RpcServerCall call) {

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

@EventHandler(topic="network.prepare")
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.



Kelven



On 11/13/12 6:20 PM, "Kelven Yang" <ke...@citrix.com> 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
>components)
>	- 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
>
>Kelven
>