Currently we are developing an application for service oriented development which is a college signature, the professor created two applications one for backend and other for front. We are using maven, hibernate and JPA. He has proposed a the following package distribution:


However I want to simplify the distribution and reduce code, so, I proposed the following distribution:


The difference here is that He exposes reused services inside wrapper classes receiving parameters. I do not expose them, I use a façade to call those when some operation is requested so that the façades receive only frontend parameters.

Are these two distributions valid SOA package distributions ?

Is necessary to have a DAO package ?

Now, I'm new to services, I don't know if these two are valid SOAs so that this is my intent when asking. We are working with SOAP but I don't know at which extent does SOAP or JSON determines if a project is service oriented.

Basically this question can be reinterpreted as: Which elements makes a SOA an actual SOA, based on that does these two projects are service oriented developments?

Note 1: My service package implements the Transactional<T> interface which I created. What does it contains? create, update, delete, findById and findAll which are basically providing a CRUD for the database.

This interface is implemented once in an AbstractService I defined and also my beans implement such interface.

Note 2: Before you could say, use Spring, CrudRepository or an archetype from maven, the professor requested to do all using Java EE 7, hibernate, SOAP and nothing more. (all by hand)

Finally, thank you before hand.

  • 1
    Nit Pick. When proposing solutions to contrast. It is usually best to visually lay them out so that the differences are obvious. Kind of like a spot the difference picture.
    – Kain0_0
    Commented Sep 8, 2020 at 4:43
  • As far as i can tell you are suggesting the removal of the Services layer on the client. Is that correct?
    – Kain0_0
    Commented Sep 8, 2020 at 4:44
  • @Kain0_0 yes, that's correct, because what my professor is doing is to call as a maven dependency the local backend project and wrapping in the frontend façades package the services in the backend. Also I remember that the facade pattern expose the facades instead of proper classes, so Idk why he's exposing the frontend services instead of the facades. Commented Sep 8, 2020 at 12:12
  • 1
    So your actual question is: What benefit does adding another set of service objects on top of the facade give over just using the facade directly in client code?.
    – Kain0_0
    Commented Sep 8, 2020 at 22:54
  • Yes, in part, but I'm new to services, I don't know if these two are valid SOAs so that was my intent when asking. We are working with SOAP but I don't know at which extent does SOAP or JSON determines if a project is service oriented. Commented Sep 8, 2020 at 23:26

1 Answer 1


Its difficult to tell if either of these two implementations are valid SOA's.

The reason why, is that SOA is a process level architecture. It takes many separate processes and integrates them using a communication paradigm, generally over a physical network.

There are languages out there such as Eiffel with its Agent syntax that allow SOAs to be trivially implemented within a single program. Each Agent is a process and the communication paradigm being message passing via memory.

What you are showing me is closer to Domain Driven Design, where you have taken a deep dive on a particular component of the system and broken out what internal functionality it has, and organised it by what knowledge it requires.

To tell if you have a SOA, the easist way would be to trace actual use cases through your system. The request going into a given component need to be at the same level, and on the same topic.

For example consider a web shop: Front-end, Api, DB

The front-end is all about the shop lets say model trains. If the user is curious about model trains, etc... then the shop can handle that.

Should it handle driver's licence paperwork? No because its not on topic. If it doesn't do this then great its a single service.

But SOA's are a backend architecture, its not meant as guidance for UI design. Though when designing a GUI, staying on topic generally helps.

The API fields requests from the Front-End. Login, Logout, What's in my cart, what products do you have, etc... Already this does not feel like one service so far there are three topics: Account Management, Cart Management, Products. Feels like three services. There may be other requests such as: pay by card, order history, shipping status that may produce even more services.

Now the next thing to consider is the Database. Should they all share the same Database? The answer is No. If they did they would share the same topic. So each service needs its own isolated database.

On the other hand there is no reason to have separate Database Servers. Consider the requests coming in: Create Table, Select, Update, Delete, Drop. Looks like the topic is about a Database. Feels like one service will do (unless there is a pressing need for a different set of features in the data store of a service).

  • This answer is definitely what I have been looking for, to begin with, I had no idea of what SOA implied. Thank you! Commented Sep 14, 2020 at 0:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.