WCF Service Dependencies
I have three wcf services A, B and C respectively, since I wanted it to be SOA (Service Oriented Architecture) how my setup works when I send a request from client to server.
- All services are self-serving Windows services.
- The client sends a request to service A (the client has no idea about other services B and C);
- Service A will eventually send this request to service B and service C.
- Service B and C sends a response back to service A, which will be sent back to the client by service A.
The problem being faced . If I make changes to the service B code and rebuild and restart the service, I have a problem getting the response back, but when I restart all other services, it works fine.
In other words, my client doesn't get a response back unless I restart all services (A, B, and C), even though I just changed the code in only one service and rebuilt it. I know this works if I restart all three services, but I want to know if this is a problem in my design way, or if this is what I have to deal with Windows self-serving services. And all services (A, B, C) are independent, since no one depends on each other.
Has anyone seen such things in SOA. I would be glad if someone can help me find a suitable solution?
source to share
-
Replace WCF between services with any queue (one service publishes something, another can read when ready). It could be anything. There may be a simple table where you read if there is something new. Maybe RabbitMQ, NServiceBus, etc., whatever works for you.
-
Define the messages that you put on the queue: commands and events. Both are simple classes with properties, no logic. Commands represent what the system is requesting (RegisterUser, PlaceOrder, ect), events represent what the system has done (UserRegistered, OrderApproved, PaymentReceived, etc.). Be honest in your actions, don't do something like "I changed all user properties on the client, now I call SaveUser (user)". Your service expects to know how to modify objects, clients only have to command what to do.
-
Never break your contract. It's easy, easier than it sounds: you can add things to messaging contracts, but you can't remove them. In other words, you just keep your contract backwards compatible.
You now have a much better design: services only exchange messages in messages, messages are backward compatible. This means that you can stop any of the services at any time without affecting others: they will continue to send messages to the queue, and when the stopped service returns again, it will catch up with processing all the material from the queue.
Then, if you want, you can use the same approach with client interactions: if instead of invoking WCF clients, they only put their commands in a queue, then service updates or other downtime will not affect the user experience.
Example: If I am using WCF to place an order or to place an item in a trade card then if there is a problem or a service is not available for service I cannot do it. I would press the button and have a nasty error. More importantly, my order will not go into the system. On the contrary, if there is a line in the middle, I only put my team in line. Now, even if my service is currently unavailable or under high load (and therefore slow), my experience still remains the same and does not degrade. It's just that my command will be processed a little later, but as a client I don't care. And my order will not be lost in this scenario. The system has become resilient and self-balanced.
There are all sorts of fantastic tricks you can do if you just queue in the middle instead of the spatial and temporal connectivity issues that come with WCF :) And what I've described is just the beginning ... :)
source to share
You might want to use a Service Bus such as NServiceBus to help you execute your functions.
The first problem you will have to address is decoupling your services with a publish / subscribe exchange template. Instead of referring to web services in a particular service, publish events that notify the appropriate services when something has happened. In your case, it will look something like this:
- The client calls a web service in service A.
- Service A publishes a Client Command Received message to which services B and C subscribe.
- Service B and C processes this event and then publishes its own events.
- Service A subscribes to both events and responds to the client.
The first and immediate benefit of using something NServiceBus is reliability. Plus, you can easily update your post without affecting your customer or your respective services. NServiceBus has full WCF integration so your client can continue to send messages to your service as before.
One of the things that makes your scenario interesting is that you cannot guarantee when services B and C will send your responses back to you. Do you keep connecting with the client until the Service receives responses? Do you need both responses before you can send a customer their response? What happens if one of the service outages occurs? What if there is a time limit that you can wait before Service A receives a response? All of these questions and more can be answered with the NServiceBus feature called Sagas. Check it.
If NServiceBus cannot be used, the situation becomes more complicated. WCF doesn't support publish / subscribe out of the box, so you'll have to bake your own. At a minimum, I would recommend using this to separate your services. Another thing is how to manage state and temporary binding in your services. Save yourself the trouble.
Other frameworks exist, but if you want a strategic, cost effective way to build a .NET solution, NServiceBus is recommended.
source to share