Now, let's discuss some special aspects of integrating SOA with frontends and backends.
The first important point to understand is where the frontend ends and SOA starts. We'll focus on frontends that are user interfaces.
Services in SOA are interfaces for B2B scenarios. These scenarios are organized in such a way that a system or component communicates from time to time with another system to read or write some data. Between these service calls, the service consumer uses its business logic to perform its task.
This means that a frontend that acts as a service consumer to some extent controls the overall behavior. This is different from a frontend that has almost no business logic and "only" presents data. For such a frontend, the workflow logically is at the server side (although the control flow still might be on the client side).
In SOA, a service serves the consumer; it doesn't control it. This even applies to process services. For this reason, process services usually do not allow human interaction. In fact, BPEL is a "batch language" that can define a service composed of other services. The service might be long running, but it can't interact with a user.
This leads to a specific programming model for the frontends. If frontends just present backend data, it's easy. They just call basic reading services, according to user input (search data, logical IDs, and so on).
If the end user wants to modify backend data, things ...