I'm sorry, I don't believe in your scenario.

If customers and orders are unrelated concepts, then it could make sense for
them to be implemented in separate services which have no business logic in
common. These two services could be completely independent. In fact, they
could be implemented by companies that have never heard of each other.

But they're not unrelated concepts. Customers make Orders. Orders are
created on behalf of Customers. At a database level, chances are that the
Orders table has a CustomerID column that is has a foreign key relation to
the Customers table. In this environment, a simple JOIN in the database will
return a set of customers along with their orders, or they could be returned
as two separate rowsets with common filtering criteria.

Given that the database can relate the two concepts, why should the business
logic layer not relate them? And given that the business logic layer can
relate them, why should you not expose a web service that can return the
related entities?

Now, I'll try assuming that "Customers" and "Orders" are not the real
entities you're trying to manipulate, but rather are just for the sake of
example. In this case, it would probably be better to refer to them as
"Entity A" and "Entity B", in order to remove any preconceptions readers
might have based on calling them "Customers" and "Orders". Assume that the
two are not directly related, but rather that Entity A contains some data
that is not a key (a street address, for instance), and that Entity B also
contains this same non-key data (street address, again). Then there is an
implicit relationship between the two entities, though they might not be
aware of it. You might have to interpose a third piece of software that can
process the non-key data to produce a key from it.  This "key" could be
manufactured against "Entity A" and "Entity B", and could then be used to
relate the two. *

In this case, you'll need an "aggregating" service that uses the "Entity A"
service and the "Entity B" service, runs it's key-manufacture algorithm on
the two non-key fields, matches the two manufactured keys, and returns
"Entity A" with the matched "Entity B".

Does that help at all, or were you asking a different kind of question when
you asked how would the function work? The brief answer is, "it would not
work as well as if the two entities were actually related".

I hope this isn't being done this way in service to some arbitrary mandate
about SOA. If it were, I'd say those who created the mandate misunderstand
SOA, which is about using appropriate services when they make sense, and not
when they don't make sense.