One of the defining principals of a "service" in this context is that it owns, absolutely, that data in the area it is responsible for, as well as operations on that data.
Copying data, through replication or any other mechanism, ditches that responsibility. Either you replicate the business rules, too, or you will eventually wind up in a situation where you wind up needing the other service updated to change your internal rules.
Using a single data service is just "don't do SOA"; if you have one single place that manages all data, you don't have independent services, you just have one service.
I would suggest, instead, the third option: use composition to put that data together, avoiding the database level JOIN operation entirely.
Instead of thinking about needing to join those two values together in the database, think about how to compose them together at the edges:
When you render an HTML page for a customer, you can supply HTML from multiple services and compose them next to each other visually: the customer details come from the customer service, and the order details from the order service.
Likewise an invoice email: compose data supplied from multiple services visually, without needing the in-database join.
This has two advantages: one, you do away with the need to join in the database, and even the need to have the data stored in the same type of database. Now each service can use whatever data store is most appropriate for their need.
Two, you can more easily change the outside of your application. If you have small, composable parts you can easily add rearrange the parts in new ways.
SOA is service oriented architecture. In SOA services are decoupled and can interact with each other irrespective of the service type. Meaning a particular service can be platform or protocol specific but SOA enables such services to interact and exchange data. This data is essentially exchanged via ESB (Enterprise service bus) which forms the backbone of any SOA architecture.
Let me go ahead and give specific example to help understand this better. One way ESB could be implemented us by using JMS servers and using XML/XSD as means of transferring data between various services. So various service will register or connect to these JMS servers and exchange data using XML format. Generally SOA suite comes bundles with so called adapters that help transforming messages to and from format understood by service and XML.
For example consider shares trading system. Messages from stock exchange come in FIX protocol. You may have build an application that expects JSON. To make these both systems work you will use SOA - FIX Adapter will convert FIX message to XML, then this xml will be transferred to JSON Adapter over ESB which will then convert to JSON as required by your system endpoint.
Finally hoping following picture makes it very clear.
Best Answer
For non technical people I would use the following concept. The whole professional world is service oriented.
This implies two major advantages:
In the world of software such architecture is implemented by defining specialized services (applications) which are dedicated to perform specific tasks and by defining protocols, which are solving problem of communications between such applications. When such architecture is deployed, you get some benefits, which can be also mapped to the real world:
If doctor is unavailable, you cannot be cured but at least you can get a cookie from the bakery! In software this means one failed service does not break the whole system.
Usually doctors and bakers do not share the same room and this allows them to operate better. Just like in software you can place each service on its own hardware.
For software world this means, better availability, maintainability, reuse, and reduced costs. Good luck!