If I have a structure like this:
request --> ESB --> Service_1
--> Service_2
Calls to service1 and 2 are in parallel. Is the ESB capable of:
The answer is yes and there are several SOA design patterns you can go for. Some these patterns might not fit your use case as your description is a little sparse in details. However based on the conceptual design here are some patterns that come to mind:
Waiting for both responses to come back in normally referred to as your aggregation strategy. This strategy will specify what to do when one end point fails etc. FOr example send a message to both endpoint A and B both with a timeout of 30 seconds. If one times out then return an error or return a partial response.
Regarding manipulating the response this is a typical use of the ESB as well. There are EIP patterns such as message translator and content enricher. Once again these might or might not be what you are looking for.
One important thing to keep in mind when designing a service like you just described is abstracting your service on the ESB to such a point that the request made by the client does not have service_! and service_2 specific in it. Let me clarify this with an example.
Lets say we have the following scenario you are hosting a hotel booking service. Every mtime a user uses this service you want to reward the user with a certain amount of points(rewards program). For simplicity sake you will have two services(hotel booking service and rewards service) combined into one service on the ESB.
The requirements for using the hotel booking service is as follows:
The requirements for using the rewards service is:
You cannot expect or want to give the users your Booking service username and password. Thus you will not expose that field on the ESB. Also if you exposed that field on the ESB and the booking service changed to an one time authorization code for example then your service on the ESB will have to change.
If you only exposed: - Guest Full Name - Arrival Date - Departure Date - Room Number - Registered Reward System User Name.
This service only exposes elements required to make a booking thus the user is isolated from changes to your back end. Always keep this in mind. Shield your service consumers as much as possible from technical details in your service providers. So if you received this type of request your will then enrich the messages going up to your providers on the ESB wait for the aggregation to complete and send a response.
If your providers change the impact is minimal. When you get these concepts right in SOA then you are well on your way to reaping benefits.