Can EJBActions be used for application client

[Dhiren Joshi]

I was going through petstore and EJBAction IMO can be used with Web Tier.
Is it possible to combine EJBAction to be used with application client.
If so can some one give me some ideas how to proceed with this design strategy.
Thanks
Dhiren

[Deepak Pant]

I would suggest you refer to Core J2EE pattern 2nd Edition. It talks about a new design pattern ApplicationService which invokes business objects.

The call sequence would be
Business Delegate->Session Facade->Application Service->Business Objects

Not sure why do you want to stick to Petstore when there are newer approaches available.

[Dhiren Joshi]

Isnt the application services implementation similar to the EJBActions .. ?
A map of the actions with a command pattern strategy. Thats why I was going with this implmenttion.
Thanks
Dhiren

[Deepak Pant]

Yes that is one strategy to implement the Application Service.

Though I am not sure if it makes sense to have two command implementations, one at the web tier and another at business tier.

The way I am doing it is moving business logic (co-ordination logic, process specific validation) from Session Facade (SLSB) to POJO classes called Application Service. One use case would typically map to one Application Service.

Session Facade provides location transparency and invokes the corresponding application service.

This way one Facade with multiple Application Services will provide the business services.

But in case you want to implement Application Service using Command pattern then you will need to pass some kind of Event (or Action) notification from business delegate to Session Facade to App controller.

[Dhiren Joshi]

Yes that is one strategy to implement the Application Service.

Though I am not sure if it makes sense to have two command implementations, one at the web tier and another at business tier.

Well it kind of gives a very flexible and exensible design.
If u need to add more functionality with the current application service how would it be extensible?

The way I am doing it is moving business logic (co-ordination logic, process specific validation) from Session Facade (SLSB) to POJO classes called Application Service. One use case would typically map to one Application Service.

Right the EJBActions also actually map a particular use case to an Action like OrderAction,CartAction CustomerAction etc which ae POJO's .They call other EJBs mapping as a use case. Only difference is that the POJO's in this case getting invoked using the command strategy.

Session Facade provides location transparency and invokes the corresponding application service.

EJBActions uses the ShoppingFacadeLocal which provides a facade to all the actions.

This way one Facade with multiple Application Services will provide the business services.

Same as EJBActions.

But in case you want to implement Application Service using Command pattern then you will need to pass some kind of Event (or Action) notification from business delegate to Session Facade to App controller.

Now that is the main problem I am facing and I dont really know how to do this. Petstore simply supports a Web based system whereas we need to support both clients.
Thanks for the discussion. It seems pretty difficult decision to go with the command strategy application services. Oddly some SCEAs have implemented EJBActions
I will think over it a bit more since I have already put lot of UML with EJBActions. Didnt think about this issue before ...

You are right about passing the event thru the business delegate and I will start thinking along these lines.

Thanks Deepak.
Dhiren

[Deepak Pant]

Now I can see where you are coming from but I am not 100% convinced that it makes your design flexible and extensible.

Business Delegate needs to pass some event/action information to the Session Fa�ade.

Session Fa�ade will require an Application Controller, and Command Mapper/Factory class to instantiate and invoke the command

Using the Command pattern introduces the challenge in passing the data related to command being executed. For example: Search service would require one kind of transfer object, create profile will require another kind of transfer object, and Login would require some other transfer object.

Also one application service can call another application service. With command pattern into play this would go thru the controller all the time.

To support two kinds of clients you can have two different application controllers (in web tier) being used by the Front Controller. The application controller can then invoke command, which will invoke the delegates etc.

Thanks for having this discussion. I learned something new today.

[Dhiren Joshi]

Business Delegate needs to pass some event/action information to the Session Fa�ade.

I agree with that. Only an Event is good like in the pet store and something similar to statemachine can resolve the EJBAction to invoke.

Session Fa�ade will require an Application Controller, and Command Mapper/Factory class to instantiate and invoke the command

Correct on this one too.

Using the Command pattern introduces the challenge in passing the data related to command being executed. For example: Search service would require one kind of transfer object, create profile will require another kind of transfer object, and Login would require some other transfer object.

Here if you look at the way petstore implmented the application service using command...They use a event which gets passed. An event could be CartEvent ,CustomerEvent,OredeEvent but for a EJBController, the gateway to the EJB tier, the transfer object is always one and the same an Event interface.
The statemachine ccan resolve the EJBAction and simply calls command.perform. So by this implmentation just one sessionfacade suffices and thats the reason why I designed using this strategy

Also one application service can call another application service. With command pattern into play this would go thru the controller all the time.

Hmm .. that piece doesnt work with the command pattern implementation would help where we need to include uses from other use cases.

To support two kinds of clients you can have two different application controllers (in web tier) being used by the Front Controller. The application controller can then invoke command, which will invoke the delegates etc.

but the application client will be a tough design to incorporate the Event mechanisms unless I make the application client come in through a similar controlelr and the enttry point is almost into the FrontController where the application controller creates all the web tier commands..
I started by implmenting a business delegate for the application client into the design though not difficult to change I still would prefer the client come entry into business tier directly to get the performance.

Thanks
Dhiren

[Deepak Pant]

You can also refer to "EJB Design Patterns" by Floyd Marinescu. This book has provided some good pros and cons of using Command pattern in EJB tier.

I have an ebook copy of this book. Let me know if you would like to refer to that.

[Dhiren Joshi]

Hi Deepak,
I need some suggestion for you. I have come with this design for a java application. does it sound too far fetched.
The app client uses the same EJB controller and so reusability of the entire business logic and the invocation is possible. Here is how.. ..
Similar to the invocation from a web application which uses events, cant the Swing client create the Event objects and pass them through the business delegate to the EJB controllers handle event method. The BD can have handleevent method which takes in a Event interface similar to the web app.
This design though requires the Swing client to be very flexible in adding new actions with XML impl. Any way the assignment doesnt really touch the Swing UI but doesnt this give a very strong maintainability as well as added performance since EJB tier is directly accessed.

Does it make any sense .. ?

Thanks
Dhiren
[ December 24, 2004: Message edited by: Dhiren Joshi ]

[Deepak Pant]

Here is what I think:

1. Peformance improves for SWING client as they make direct RMI calls to the application server. Requirements states that peformance is must for Agents so I guess they are indicating that use RMI.

2. Good idea to increase the re-use by routing everythinh thru same EJB controller for both Web and Swing clients.

3. But I am not sure if Command pattern is maintainable, because:
- Cannot throw custom exceptions unless you wrap them somehow. Every command throws generic BusinessException or CommandException.
- Cannot control transaction boundaries as the transaction is decided by the Session Facade EJB's transaction attribute. You may have to add addn Session Facade EJBs for different transaction behavior
- Painful for for large projects where one ends up with lots and lots of events. Same logic gets copies over again and again as the Command's do not call each other or else Command chaining is used.

I hope this helps
[ December 25, 2004: Message edited by: Deepak Pant ]

[Dhiren Joshi]

Cannot control transaction boundaries as the transaction is decided by the Session Facade EJB's transaction attribute. You may have to add addn Session Facade EJBs for different transaction behavior

I didnt quite understand this bit. Since the transaction is handled at the session facade,the business delegate would call the EJB controller directly so how is the transaction bounderies not defined/propogated... . Can you clarify.

- Painful for for large projects where one ends up with lots and lots of events. Same logic gets copies over again and again as the Command's do not call each other or else Command chaining is used

Command do not call each other but one EJB Action is a use case execution similar to PetStore.
So ending with lots of Events is acceptable since a framework handles the underlying invocation. I am not sure how command chain works but since Petstore doesnt have command chain implementation i will ignore that for now.
I am concerned about the transaction issue which u brought up . I am not able to clearly figure out how it would impact transaction context.

My main concern is the impact passing event directly to EJB controller would have on the application client architecture ilities. I am thinking they would be an improvement and more closer to the reuirements. Please give me your thoughts.
Thanks
Dhiren