How to enrich a simple two endpoint SOAP application to become enterprise level?

Question

Imagine you have some exchange of data between two endpoints (webservices or let's call URL). Data can travel in any way (Xml, Json, GET, POST) it doesn't matter.

I've got the source code of the first endpoint (I drawed it on the left). The second one is from a third party and will call back my infrastructure on a third endpoint (which is also part of my infrastructure).

I would like to implement some session / state to relate the first call to their callback. And I would also like to add distributed logging, support for problem solving in a production environment, configuration, performance monitoring, a dashboard, and so on.

What kind of consideration should I do in facing the design of this kind of architecture?

Let me clarify with an example (which answers to @SparKotॐ comment)

I should log the first call and understand if the third party is calling me back or not.

I can do this only if my "3rd party" caller Class (the white box higher on the lef) and the Class called from the "3rd party" (the white box lower on the lef) shares some logging infrastructure. How would you implement this?

Possibilities are:

• Share a database
• Share a message queue
• Share a WCF service
• Share some AppFabric cache
• What else?
• Pipeline?

Which consideration would you make about this tracking service? Should both my class being hosted on the same server? What kind of question would drive you to design the architecture which transform two simple WebClient.Open request into something which is more traceable and fault tolerant?

Answer 1

I would look at a shared logging infrastructure something like loggly (https://www.loggly.com/) or logstash (http://logstash.net/).

If you have every call generating a requestId for each call and have a conversationId for the whole conversation. Pass these in the headers of each call, each component can log metrics, info, errors etc using these ids. And you can then extract useful information out of your logging platform that will let you drill into each call in detail on both sides of the call (client and server).

Answer 2

This answer is just to document the first effort I did for solving problems. It's not complete so it would not be the accepted answer.

However there is still no other complete answer here. Since that I hope you will appreciate my effort.

---

Actually the code is structured as in the first design. But I think it's not very readable.

Problems before the architectural changes

• The namespaces name are saying nothing of the responsability of each class
• Is it really useful to split between DAO and BLO layer a so small architecture? There is almost no logic.
• The logic / responsability of the BLO is not identifiable by the names of class / methods / namespace
• What is UserType? The namespace is not grouping it with any other class..
• Config class is a good name for me since it identifies a functionality. But It's the only class with a precise purpose specified by its name.
• Get3rdPartyUrl and logging in (to that url) could all be put together in a same class, while InitializeConfigValue and ParseErrorMessage could be put into some other Help class.

Contacting a 3rdParty WS is reusable. Everything should inherit from just one interface also defining logging.

Class design before refactoring

Class design after refactoring