title: Service Oriented Architecture and Loose Coupling vs SQL JOINS
body: <p>Let's suppose we have got a SOA infrastructure like the one painted below and
  that every service can run on a different host (this is especially valid for the two extra-net service "web site" and "payment system").</p>
  
  <p><img src="https://i.stack.imgur.com/kuvVT.png" alt="SOA infrastructure"></p>
  
  <p>Clearly we have got a data (persistence) layer. Suppose it's implement through EJB + JPA or something alike.</p>
  
  <p>If we want to join data (in user UI) between the different services I see at least a couple of alternatives:</p>
  
  <ul>
  <li><p>we want to do efficient JOINs at RDBMS level so we have a package (ie. persistence.package) that contains <em>all</em> the entities and session facades (CRUD implementation) which in some way has to be shared (how ?) <em>or</em> deployed for every service. That said, if I change something in the order schema I must redeploy this packages introducing tight coupling between pretty much everything. Moreover the database must be unique and shared.</p></li>
  <li><p>to avoid such issues, we keep an entity package for each different service (i.e. order.package) and let the services communicate through some protocol (soap, rest, esb, etc.). so we can keep data locally in each host (share nothing architecture) and we don't need to redeploy the entity package. But this approach is terrible for data-mining as a query that must search and return correlated data between multiple services will be <strong>very</strong> inefficient (as we cannot do SQL joins)</p></li>
  </ul>
  
  <p>Is there a better / standard approach to the issues pointed above ?</p>