Facade vs Command

[jasonab]

Our current application (which we're refactoring) is a fairly traditional J2EE model built on session and entity beans. We're moving to Tapestry, Spring and Hiibernate.

One difference, though, is that the old app, instead of having a standard facade, is based off command/event objects, which are passed to a single session bean on the biz tier. That bean then uses XML to map the event to EventHandlers, which then access the entity beans and perform the business logic.

In our refactoring, we haven't yet decided whether to unroll this command facade into a standard facade with multiple manager beans, or keep the event model and have the central manager then delegate to other handlers.

Most applications using Spring (AppFuse, Hispacta, all the PetStores) use the multiple manager implementation. While I find that way simpler (no event objects to track), I can't see a reason why the command way is inherently inferior.

Has anyone done the command/event way in Spring, and is the facade pattern superior?

[Alarmnummer]

Our current application (which we're refactoring) is a fairly traditional J2EE model built on session and entity beans. We're moving to Tapestry, Spring and Hiibernate.

One difference, though, is that the old app, instead of having a standard facade, is based off command/event objects, which are passed to a single session bean on the biz tier. That bean then uses XML to map the event to EventHandlers, which then access the entity beans and perform the business logic.

In our refactoring, we haven't yet decided whether to unroll this command facade into a standard facade with multiple manager beans, or keep the event model and have the central manager then delegate to other handlers.

Multiplexing the event (everyone creates an instanceof an event, and drops it on a single channel), and later demultiplexing it (picking up an event from that channel, finding the correct handler and dropping the event on that handler) hmm.. Is there a need for that single channel? Is it not easier to that every one drops his command/event to the correct handler?

You design has some advantages:
1) there is a single channel, so securty is easier to implement because there is a single point of access (Could be handy in a situation where the client is a different application)
2) there is no reference between the event producer and the event handler.
3) makes it easier the control the number of resources being used, because there is a single point of acces

But your design makes a system more complex. So.. is there a need for the advantages? If not I would drop your approach and let event producers drop the event to the right event handler.

[manifoldronin]

You design has some advantages:
1) there is a single channel, so securty is easier to implement because there is a single point of access (Could be handy in a situation where the client is a different application)

I'm not even sure this is a real advantage. With this single entry point chances are whatever security enforcing code would still have to peek into a particular command/event object before being able to make any sensible authorization decision.

2) there is no reference between the event producer and the event handler.

This is true. Although this would present value only when the consuming code is loosely coupled with the biz tier and behind, and only when all those "events" are truly of the fire-and-forget type, which I doubt is the case for the OP.

3) makes it easier the control the number of resources being used, because there is a single point of acces

All the "managers" would be singletons, too. It's probably not much difference between 5 singletones and 1 singleton from resource control standpoint.

But your design makes a system more complex. So.. is there a need for the advantages? If not I would drop your approach and let event producers drop the event to the right event handler.

I realize so far this reply looks like a rebuttal to your post, while I actually agree with your bottom line.

[Alarmnummer]

I'm not even sure this is a real advantage. With this single entry point chances are whatever security enforcing code would still have to peek into a particular command/event object before being able to make any sensible authorization decision.

That is right. But because it is the only entrance to the system, this is the only gate that has to be checked. I haven`t applied this technique much, but it can be usefull (it depends on the requirements).

Btw: an interresting book about this subject is:

Software Fortresses: Modeling Enterprise Architectures

This is true. Although this would present value only when the consuming code is loosely coupled with the biz tier and behind, and only when all those "events" are truly of the fire-and-forget type, which I doubt is the case for the OP.

If the topicstarter doesn`t need this 'advantage', he is paying the price for something that he doesn`t need. That is what I want to make clear in my previous post.

3) makes it easier the control the number of resources being used, because there is a single point of acces

All the "managers" would be singletons, too. It's probably not much difference between 5 singletones and 1 singleton from resource control standpoint.

It depends.. if there are more entrances it will be more difficult to check.

This design could also be handy if you don`t want to deal with any kind of concurrency control in the code behind the entrance. Some time ago a made the backend of an auction and by storing all the commands in a single queue, and only letting a single thread deal with the commands, the concurrency control was childsplay.

I realize so far this reply looks like a rebuttal to your post, while I actually agree with your bottom line.

That was the most important part

I wanted to make clear that there are advantages to his approach, but these advantages introduce (a lot of) complexity. And I only want pay for the price of complexity, if I gain something by that complexity. Just paying the price, makes life more difficult than it has to be. (read: less profit)

[jasonab]

One difference, though, is that the old app, instead of having a standard facade, is based off command/event objects, which are passed to a single session bean on the biz tier. That bean then uses XML to map the event to EventHandlers, which then access the entity beans and perform the business logic.

event on that handler) hmm.. Is there a need for that single channel? Is it not easier to that every one drops his command/event to the correct handler?

In the old app, that single channel was a stateful session bean. He was responsible for logging that an event had taken place, event notifications (to users who requested that), and session management.

It also decouples the implementation somewhat, since you don't have to call a specific bean; you call the controller with the event.

You design has some advantages:
2) there is no reference between the event producer and the event handler.

Right, that's the main one I see.

But your design makes a system more complex. So.. is there a need for the advantages? If not I would drop your approach and let event producers drop the event to the right event handler.

And I agree with this as well - maintaining all the different events, even though there's not much code in each of them, is still more complex than having a simple facade. For that matter, if we ever wanted to run web services, we'd want the facade instead of having strangers pass us events.

I believe the team's main concerns are not changing more than we have to at once. I'm concerned, though, about trying to wire the handlers into the controller, since that will be a lot of references from one place. I like the idea of the managers having smaller pieces of responsibility.

[Martin Kersten]

I believe the team's main concerns are not changing more than we have to at once. I'm concerned, though, about trying to wire the handlers into the controller, since that will be a lot of references from one place. I like the idea of the managers having smaller pieces of responsibility.

I just thought about the Command pattern using. Guess what, check out how invocations are handled on interfaces. Normally you add a proxy and serialize the invocation. Than you transmit the serialized invocation to the server and once that is done, it gots deserialized by the responsible controller and gets executed using reflection and the appropriated objects. (or handler/listener/command-processor or whatever)

Doesn't the invocation look like a command here? Boy I guess I have to tap my shoulder on that thought (Don't take it serious, I just got this thought for the first time...). So there is no much binding here. Just make one single interface be responsible to dispatch any invocations. Also you can change the proxy for whatever you want (it can actually create real commands to address any interface-language).

I think this can be called a replacement of a command factory by a proxied business interface to make the whole command stuff transparent on both ends. And all those proxies may also add additional informations, impose security policies, certificates, log stuff and everything. Looks like a transparent adapter using proxies.

I have to really write that down... . I never thought of this that way! But Burlap etc. seams to follow this anyways... .


Many thanks on that and cheers,

Martin (Kersten)

[Alarmnummer]

Another important thing to realise is that there are 2 kinds of commands. Commands that have logic how they are going to be executed, and commands that don`t.

I don`t think you want to serialize objects from a client to a server that allows commands to have their own logic because there are many problems with this aproach.
1) security
2) tight coupling

[jasonab]

Another important thing to realise is that there are 2 kinds of commands. Commands that have logic how they are going to be executed, and commands that don`t.

Right, the ones we have now are the second - no logic in them, just fodder for an XML lookup and then load the responsible class.

[Martin Kersten]

I don`t think you want to serialize objects from a client to a server that allows commands to have their own logic because there are many problems with this aproach.
1) security
2) tight coupling

Security is no issue when deserializing a class. You know you need the class in order to deserialize it. Therefore the compromising class just must be within the VM's 'sandbox'. So by deserializing the command/invocation, the command is created in a trusted environment (within the sphere of trust).

[Alarmnummer]

I don`t think you want to serialize objects from a client to a server that allows commands to have their own logic because there are many problems with this aproach.
1) security
2) tight coupling

Security is no issue when deserializing a class. You know you need the class in order to deserialize it. Therefore the compromising class just must be within the VM's 'sandbox'. So by deserializing the command/invocation, the command is created in a trusted environment (within the sphere of trust).

*Makes a note*
Study serializing (I haven`t done any client/server serializing for quite some time).