问题
I worked in the past on building a data processing application structured using a service-oriented architecture. I had a series of services that would all be managed from a master service which would call all services serially to process my data.
I ran into something I didn't like in that the services had to provide status and error feedback to the master service and I had to code everything from scratch.
My question is, are there standards out there for inter-service communications and management. Things like message format, error recovery, and status reporting are of particular concern to me. I'm going to have to rebuild a SOA in the future and I don't want develop "from scratch" but would rather conform to a greater standard. I know that some of the answers to my question will be based on my business requirements, however I want to see if there is anything out there on this first.
Thanks,
mj
回答1:
ACID transactions when orchestrating services
When orchestrating services you would want to generally avoid orchestrations where you have multiple interdependent calls that update/create data in order to ensure consistent state of data in the backend systems. However, in reality there often are scenarios that require multiple such steps, and you essentially end up having a transaction that consists of multiple service calls across a set of services. Of course, you’ll want to ensure that your process has occurred as an ACID transaction.
The classic approach that comes to mind to handle this is using a 2PC – 2-Phase-Commit by establishing a common transaction context for all service calls within the transaction. However it is very rarely seen in service oriented architecture, because it is either too expensive to do or it is outright impossible. It also couples your services to the transactional context.
The more practical approach is to use a method called Compensaton. It’s gives you much better flexibility and decoupling compared to 2PC. In compensation, if a step fails, and some successful writing has already been done prior that, you compensate by doing something appropriate depending on your context – e.g. you can call another service to rollback the changes, or another operation of the existing service that does the deletes/deactivates the record. This approach makes the business logic (in your process service in your case) a bit more complicated, but it gives you the ability to create services way more easily without complicating them with having to care for transactional context.
What I’ve seen in my practice is that often services that will be used in transactions are designed with opposite operations in order to allow for compensation - e.g. in a service called Users you will have operations like CreateUser and DeleteUser.
If you really want to follow formal standards and your services are web services, you can see WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity specifications here and decide for yourself if it is an overkill or not.
Status reporting
I’ll just share my experience here, bea. It‘s quite handy to have each service report three common statuses (you might have more depending on service context, but all your services can return these three):
OK – the operation succeeded (nothing interesting happened, everyone is happy but kind of bored)
Recoverable Error – it tells your process that an error that quite possibly will resolve if you retry calling the service. Example for this is a system is busy or offline temporarily. With such error, you may setup your process to retry multiple times, before giving up and making a rollback.
Non-Recoverable Error – an error that no matter how many times you retry, it won’t be resolved – for example your request is malformed, or critical mandatory input parameters are missing. In these cases you make a rollback. Note that when talking about error reporting, you must be thinking about logging all service activity as well.
Hope this helps!
来源：https://stackoverflow.com/questions/29658092/service-oriented-architecture-communications-standards