Why Service Isn't A ServiceFacade, But ServiceFacade Is Sometimes A Service...
You could design applications with Services only - no problem. You could even go with a single annotation @Stateless and combine your "Services" randomly:
@Stateless public class SomeService{
@EJB AnotherService service;
}
@Stateless public class AnotherService{}
It would even work consistently because of the EJB 3 defaulting. The first Service would start a transaction - all other will reuse it. The only problem are the fallacies of distributing computing and especially the granularity ("latency is zero"). Regardless, what platform or even programming language you are using, you should always be aware of the impact of distribution/remoting.
The general solution is the introduction of a boundary, which main responsibilities are:
- Providing coarser granularity
- Ensuring consistency
- Providing a defined entry point which can be easily decorated with aspects / interceptors
- Exposure of components (what components are we will cover later) functionality to remote clients via IIOP, REST, SOAP, JMS, Hessian etc...
The manifestation of a boundary is the ServiceFacade - the facade to Services. The Services just rely on a certain amount of cross cutting aspects and concentrate on the realization of business logic. The ServiceFacade only invokes Services in consistent way, mostly using transactions. The Services can remain independent of each other - the ServiceFacade combines them. These are the typical responsibilities of a GoF Facade.
For simple use cases like CRUD, there is nothing to coordinate. If you would insist on layering, you will get a delegating (empty) ServiceFacade and an almost empty Service. For simple cases I just put the CRUD logic into the ServiceFacade - without having a dedicated Service. This violates the Separation of Concerns and Single Responsibility Principle and isn't elegant - but is pragmatic and lean. In worst case you can still extract the code into a Service afterwards. So sometimes a Service Facade can be a Service, but not vice versa...
I will cover ServiceFacade in more detail in upcoming posts. This is a highly condensed excerpt from my current book (see page 56 first edition / orange book, or page 83 second edition / green book and the Service pattern), a less condensed excerpt you will find at javaworld.com (Lean Service Architectures With Java EE 6).
I checked-in (pushed) the ServiceFacade in several variations into kenai.com.
I got many questions regarding the difference between a Service and a Service Facade. Hope its a bit clearer now.
I can definitely relate to your post. The senior developer in the parent project is so obsessed with layering that even simple CRUD functionality were delegated to other session bean, i.e. a Service facade that does not assembles services but rather delegates to other services :(
Posted by Uy Jerwin Louise Vergara on June 18, 2009 at 09:10 PM CEST #
@Uy,
years back developers were paid by Lines of Code (LoC). Nowadays some architects seem to be paid by Number Of Layers (LoL) :-)
Seriously: the question always is - what happens in worst case. If it is acceptable, you should start with a simple architecture and scale later...
thanks for your comment!,
adam
Posted by Adam Bien on June 18, 2009 at 09:53 PM CEST #
Hi Adam,
first of all, congratulations to your book release!
About your Service Facade Pattern i have one thing to add.
You could write something about the package structure. I see you put both the interface and the bean within the same package. That's how i did it, too. Is this the best practise? I know some architects who would tell you to put the interfaces in an own project called *Client.
I am really looking forward to EJB3.1. Because, i most of my Services and Service Facades it was not necessary to have an interface, i had no benefit, so it was just useless code...
Greetings Daniel
Posted by Daniel on June 19, 2009 at 09:55 AM CEST #
Hi Adam
I working currently on a project where the developers don't make a difference between vertical services (use case based services as you described them) and the horizontal services (services called from vertical services or other horizontal services from other components).
I prefer to make the difference between this two types of services because the API is different. The vertical services are used by service facades and these are usually driven by the UI. The horizontal services are more like domain services and they are more developer-driven.
What do you think about this approach? Am I completely wrong?
Patrick
Posted by Patrick on June 19, 2009 at 10:52 AM CEST #
@Daniel
The only reason for putting the interfaces in another package is for remoting, i.e. a jar containing all the interfaces w/o the implementation.
@Partrick
It is a matter of distinguishing fine grained and coarse grained services. The reason why the Service Facade is effective because it exposes a coarse grained functionality which is normally the business logic. Fine grained services are usually your data access tier which can be replaced by JPA.
Posted by Uy Jerwin Louise Vergara on June 19, 2009 at 06:18 PM CEST #
great post! thanks!
Posted by Santi on July 26, 2011 at 06:00 AM CEST #
@Daniel
I also put Interface and Implementation in the same package but I always create 2 separate modules (one with the contract and one with the implementation).
Posted by Laurent on February 07, 2012 at 11:29 AM CET #
Hi,
Nice post. I think Service facade is bit confusing by the name. It can be renamed as Service Orchestrator or Service Co-ordinator. Your thoughts appreciated.
Cheers ...dhrubo
Posted by Dhrubo on February 23, 2012 at 06:06 PM CET #