[Session Fa�ade/POJO Fa�ade] VS [Application Service]

[Gundum Hoi]

I am reading �Core J2EE Patterns�. And I am building a relatively simple webapp � but it might grow larger next time.

Can anyone tell me what is the difference(s) between :
[Session Fa�ade/POJO Fa�ade] VS [Application Service] ?

I don�t seem to understand the differences between them. To me, all of them separate the front part of the application which sees things in terms of Use Cases and the back part of the application which sees things in terms of biz components like Business Objects and Data Access Objects.

OK� maybe among the 3, the obvious thing about Session Fa�ade is that it is specifically referring to the Session Bean EJB technology � and that it is useful to serve remote clients.

But for local clients, should I go for :
1) Session Fa�ade Pattern � with EJB Local Session Bean technology or
2) POJO Fa�ade Pattern � with just POJO or
3) Application Service Pattern � with just POJO
??

If I do not want the �complexity� of EJB, which will need me to deploy into a EJB container instead of just a simple servlet container such as Tomcat, I might not use Session Fa�ade. But how to choose between POJO Fa�ade and Application Service ? What are the differences between them ?

Please help, thanks.

[Stan James]

I'm looking HERE and don't see Application Service. Is this the right source?

Session Facade and POJO Facade (which I don't see there either) sound like they differ only in that Session Facade supports remote access. Facades are nice to provide large-grained services and hide all the details of how they work.

And I'm with you - don't use EJB unless you really need it. It does a lot of useful things for you but the initial learning curve is formidable.

[Gundum Hoi]

Stan James, 1st of all, thank you for taking the time to reply.

You are looking at the 1st edition of the book.
Application Service is in the 2nd ed - and marked as "new".
See http://www.corej2eepatterns.com/Patterns2ndEd/index.htm

Session Facade and POJO Facade (which I don't see there either) sound like they differ only in that Session Facade supports remote access.

You are right. Yes POJO Facades are for local calls and Session Facades, which are implemented as EJB Session Beans, are for remote calls. This is clear. My question is actually more towards the difference(s) between the 2 types of facades VS application service.

I am still trying to understand�
[ August 18, 2006: Message edited by: gundum hoi ]

[Gundum Hoi]

Facades are nice to provide large-grained services and hide all the details of how they work.

Yes... agree. Seems to me that it is the same for Application Service. This is where I am confused about.

[Ilja Preuss]

At http://www.corej2eepatterns.com/Patterns2ndEd/ApplicationService.htm it states

Application Services provide the background infrastructure for Session Fa�ades, which become simpler to implement and contain less code because they can delegate the business processing to Application Services.

Sounds to me like an Application Service basically *is* a "POJO Facade"...

[Stan James]

D'oh! I included "sun" in my google search for J2ee patterns. Never found 2nd ed. Thanks, it's bookmarked now!

[Gundum Hoi]

Stan, you are welcome.

My current understanding is :

- On the whole, a "Service" layer and a "Facade" layer is generally the same thing. Both has this major goal - to separate the Use Case side of things (front side, coarse-gain) with the Biz Component side of things (back side, fine-gain). This "Service"/"Facade" layer is the most front portion within the biz tier.

- The patterns "Session Facade"/"POJO Facade" and "Application Facade" is nothing more than patterns that further split the "Server"/"Facade" layer into 2 more layers : 1) the one in front being either Session or POJO Facade and 2) the 2nd one being "Application Facade" layer.
So... if you are using Struts and BO/DAO :

Struts Action class (or other types of client) -calls-> Session/POJO Facade -calls-> Application Service -calls-> BO/DAO/Other App Service

- "Session Facade"/"POJO Facade" is nothing more than just a layer of "skin" for the "Application Service". "Application Service" is the "meat" or "flesh", which contains the bulk of the biz logic code.

- "Session Facade" is there mainly to enable POJO "Application Service" classes to receive remote calls. In other words, "Session Facade" receives remote calls on behalf of "Application Service". This is because "Session Facade" classes are EJB Session Beans and "Application Service" classes are POJOs.

Would appreciate if someone can confirm/"solidify" my understanding above.
[ August 20, 2006: Message edited by: gundum hoi ]

[Gundum Hoi]

For a simple web app...where my biz layer does not need to receive remote calls, I think the best is to do away with "Session Facade"/"POJO Facade" altogether...and just have the "Application Service" layer classes. "Application Service" layer will then be the "most front" portion of the biz tier.

If you use Struts (presentation tier), for most of the projects, the calls between the Struts action classes and your biz tier classes are local calls anyway.

What do you think ?

[Ilja Preuss]

For a really simple web app, you could probably do without an application layer, too.

Remember that all the patterns are there to resolve some problems/forces. Not in every system, those problems will arise, though. If you apply patterns without feeling the forces that should you to lead using them, you are just adding unneeded complexity.

So, if you think about applying a pattern, read the forces section carefully. Think about whether you are feeling those forces. If you are *really* experienced, you might also want to think about how likely those forces are to show later, but that's always a slippery slope.

You can always introduce a pattern later, when you feel it becomes necessary - it's much easier than reducing unneeded complexity. If you feel unsure about being able to do this, get a good book on refactoring...

[Peer Reynders]

Originally posted by gundum hoi:
On the whole, a "Service" layer and a "Facade" layer is generally the same thing. Both has this major goal - to separate the Use Case side of things (front side, coarse-gain) with the Biz Component side of things (back side, fine-gain). This "Service"/"Facade" layer is the most front portion within the biz tier.

Not exactly. Don't be mislead by the peculiaries of the Session Fa�ade which is constrained by its usage of EJBs. As Martin Fowler states, a Session Fa�ade is merely a remote interface applied to several Transaction Scripts (110). Normally a Fa�ade (article: Understanding The Facade Pattern) should not contain any business logic - and a Session Fa�ade in its original layout will contain business logic. It's only once you push your business logic into the Application Service that the Session Fa�ade starts to resemble a Remote Fa�ade. A POJO Fa�ade is simply a Fa�ade in front of a bunch of POJOs; the business logic is contained in the POJOs and they are not considered part of the POJO Fa�ade. So it would probably be more accurate to state that in most cases a service layer will contain a Fa�ade to expose its services to its clients as this will minimize the service clients dependency on the actual implementation of the service.

If you look at Eric Evan's definition of a service:

SERVICE � An operation offered as an interface that stands alone in the model, with no encapsulated state.

it becomes clear that the Fa�ade is the interface offered by the service.

Originally posted by gundum hoi:

- The patterns "Session Facade"/"POJO Facade" and "Application Facade" is nothing more than patterns that further split the "Server"/"Facade" layer into 2 more layers : 1) the one in front being either Session or POJO Facade and 2) the 2nd one being "Application Facade" layer.

Forget about the Session Fa�ade, it only confuses matters. The service client accesses the service through the Fa�ade, the Fa�ade in turn accesses whatever implements the service, i.e. whatever contains the business logic, that could be an object model implemented with POJOs, or just a bunch of Transaction Scripts.

Originally posted by gundum hoi:

- "Session Facade" is there mainly to enable POJO "Application Service" classes to receive remote calls. In other words, "Session Facade" receives remote calls on behalf of "Application Service". This is because "Session Facade" classes are EJB Session Beans and "Application Service" classes are POJOs.

In this context you should actually be talking about a "Remote Fa�ade" which makes clear that there is absolutely no business logic in the "Remote Fa�ade". If you use "Session Fa�ade" you leave the possibility open to business logic being part of the "Session Fa�ade". To that effect "a Remote Fa�ade using EJB Session Beans" might actually be what you are looking for; that description is more constraining than a "Session Fa�ade" would be.

[Stan James]

should not contain any business logic

I'm not sure what that means, if for no other reason than we haven't agreed on what "business logic" is. A facade may well sequence calls to several finer grained objects. Does that count? A higher level interface has to contain some logic ... or do you see a place for one that simply passes all method calls through to some other object?

[Gundum Hoi]

By Stan James :

I'm not sure what that means, if for no other reason than we haven't agreed on what "business logic" is. A facade may well sequence calls to several finer grained objects. Does that count? A higher level interface has to contain some logic ... or do you see a place for one that simply passes all method calls through to some other object?

Good question you have raised there James. I would like to clear that up too - I would like to have a clear understanding of what "business logic" means. Does a "sequence of calls to several finer grained objects" qualify as "business logic" ? I find that most patterns book use the term "business logic" rather loosely. They do not define the term clearly before they use "business logic" in all their lengthy explanations.

My personal opinion : A "sequence of calls to several finer grained objects" IS "business logic".

[Peer Reynders]

Granted the term "Business Logic" is a bit of a gray area. Maybe if you go with the more academic term "Domain Logic" things might be a bit easier. Ultimately any processing that occurs in direct support of the core Domain Model is "Domain Logic". Any remaining "logic" probably exist for a different reason.
Eric Evans states in Domain Driven Design � Tackling Complexity in the Heart of Software, p.366-367:

The FACADE does not change the model of the underlying system. It should be written strictly in accordance with the other system's model. Otherwise you will at best diffuse responsibility for translation into multiple objects and overload the FACADE and at worst end up creating yet another model, one that doesn't belong to the other system or your own BOUNDED CONTEXT. The FACADE belongs in the BOUNDED CONTEXT of the other system. It just presents a friendlier face specialized for your needs.

This explanation is served in the context of the implementation of an Anticorruption Layer between two different Bounded Contexts (object models). The interesting thing is that "Your Subsystem" doesn't access the anticorruption layer through the Fa�ade, its access points are the services. It is the Anticorruption layer that accesses the "Other Subsystem" through the Fa�ade:

Your Subsystem
--- anticorruption layer begin ---
Services 
Adaptors - Translators
Facade
--- anticorruption layer end   ---
Other Subsystem

In the GOF Fa�ade write up it is also stated:

Participants

Facade

knows which subsystem classes are responsible for a request.

delegates client requests to appropriate subsystem objects.

subsystem classes

implement subsystem functionality.

handle work assigned by the Facade object.

have no knowledge of the facade; that is, they keep no references to it.

Collaborations

Clients communicate with the subsystem by sending requests to Facade, which forwards them to the appropriate subsystem object(s). Although the subsystem objects perform the actual work, the facade may have to do work of its own to translate its interface to subsystem interfaces.

Clients that use the facade don't have to access its subsystem objects directly.

So the Fa�ade's responsibility is strictly to receive requests from the clients and to delegate the request to the appropriate part of the subsystem. GOF makes some allowance for "translation". However as Evans points out any heavy duty translation that may change the exposed model should not be part of the Fa�ade itself but should be performed by separate Adaptors with the necessary Translators. So one could argue that "exposing a coarser-grained interface" cannot be accomplished by a Fa�ade alone. On the other hand, sequencing logic, management of intermediate results (objects) for a single request to "simplify" the interface can be part of the Fa�ade and as such aren't considered "Business Logic", though most certainly some superficial "Business Rules" are being observed - but any explicit "Business Logic" should reside in the subsystem itself (or parts thereof).

[Peer Reynders]

Originally posted by gundum hoi:
My personal opinion : A "sequence of calls to several finer grained objects" IS "business logic".

Probably most people will agree with you - and you may be right. However:

A has a C
C is a B
D is a B

Does that mean that A has a B? A has a special B, a B that is a C. A cannot take D even though it is a B.

By the same reasoning one can accept that "sequence of calls to several finer grained objects" IS "business logic" and that a Fa�ade can contain a "sequence of calls to several finer grained objects". However that does not imply Fa�ade can contain any type of "business logic" - it can only contain a very particular type of "business logic" - scripts that are roughly equivalent to "sky-level" use cases.

I don't object to:

A "sequence of calls to several finer grained objects" IS "business logic"

A Fa�ade can contain a "sequence of calls to several finer grained objects".

I argue with:

A Fa�ade can contain "business logic".

That statement is so inaccurate that it is misleading.
[ August 21, 2006: Message edited by: Peer Reynders ]