BigSmoke inventory - Adapter or Facard?

[Sandeep Krish]

Hello Dear Ranchers,

BigSmoke has an existing inventory system which is assumed to be intact as per my design proposed for their system enhancement. So I decided to use an Adapter to interface with inventory system as that would abstract inventory. Is this a right approch? What do you guys think.

warm regards
-Sandeep

[Cameron Wallace McKenzie]

Abstraction through interfaces is always an optimal design. It sounds good to me!

-Cameron McKenzie

[Sandeep Krish]

Thank you Cameron.
Do you think a business delegate is an overkill between the Adapter and Front controller? That is how i designed and the reason was to take care of exception and to abstract out the business method further. Adapter handling the business method exception dosen't look so good for me.

Have a good day
-Sandeep

[Cameron Wallace McKenzie]

I always use a business delegate.

-Cameron McKenzie

[Sandeep Krish]

Thank you again.

-Sandeep

[J J Wright]

I always use a business delegate.

Why? In EJB 3.0 the business interface is precisely that - the business interface. It doesn't throw checked infrastructure-related exceptions like EJB 2.1. In EJB 3.0, the business delegate and the EJB interface end up being identical, in which case there's no value in introducing a new layer. How does business delegate fit in with frameworks like Seam / WebBeans?

[J J Wright]

That is how I designed and the reason was to take care of exception...

What exceptions are you taking care of? Business (i.e. application) exceptions should be propagated to the client, otherwise there's no point in throwing them. The original intent of Business Delegate was to handle infrastructure related checked exceptions like RemoteException, FinderException, or CreateException. As I mentioned in my previous response, these exceptions don't exist in EJB 3.0.

... and to abstract out the business method further

Why? If you need to further abstract the interface of a boundary class, surely there's something wrong with the original interface. It sounds to me like you're mixing up Business Delegate with Service Facade.

Adapter handling the business method exception doesn't look so good for me.

That depends on where you want to introduce failover. I don't think Business Delegate was ever intended for that purpose. Proxy - yes, Business Delegate - no.

[Sandeep Krish]

What exceptions are you taking care of? Business (i.e. application) exceptions should be propagated to the client, otherwise there's no point in throwing them. The original intent of Business Delegate was to handle infrastructure related checked exceptions like RemoteException, FinderException, or CreateException. As I mentioned in my previous response, these exceptions don't exist in EJB 3.0.

I am so used to EJB2.0 and did not remember the new feature available in EJB3! But still business delegate holds good due to following reasongs
1. It is desirable to minimize coupling between presentation-tier clients and the business service, thus hiding the underlying implementation details of the service, such as lookup and access.
2. Clients may need to implement caching mechanisms for business service information.
3. It is desirable to reduce network traffic between client and business services.

Why? If you need to further abstract the interface of a boundary class, surely there's something wrong with the original interface. It sounds to me like you're mixing up Business Delegate with Service Facade.

I too felt that there is something wrong the original interface and that is the very reason I posted this message! Service Facard is new for me so need to study that first before making any comments.

That depends on where you want to introduce failover. I don't think Business Delegate was ever intended for that purpose. Proxy - yes, Business Delegate - no.

I agree that BusinessDelegate is not intended for this purpose but since I decided to use it, I felt the extra functionality would beef up the Business Delegate.

Regards
-Sandeep

[J J Wright]

It is desirable to minimize coupling between presentation-tier clients and the business service, thus hiding the underlying implementation details of the service, such as lookup and access.

Dependency injection solves this problem.

2. Clients may need to implement caching mechanisms for business service information.
3. It is desirable to reduce network traffic between client and business services.

Remote clients.

I too felt that there is something wrong the original interface and that is the very reason I posted this message!

If you feel the interface is wrong then you need to go back and clearly define the boundary classes in the business tier. I don't see Business Delegate as the way to fix a poorly designed service.

Good luck

[Cameron Wallace McKenzie]

Really good points by Jonathan and Sandeep.

Indeed, with EJB3, many of the tried and true design patterns have much less significance than they did in the past.

I actually put together a thread on Which Design Patterns are Not Needed in JEE5. It's an interesting discussion.

-Cameron McKenzie

[Sandeep Krish]

Thanks Cameron and Jonathan! I am revisiting design.