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).

enter image description here

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?

  • 2
    Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask
    – gnat
    Commented Feb 11, 2014 at 13:27
  • 1
    I will be working on it for the next days. I'll give a self answer to share my errors and success.
    – Revious
    Commented Feb 11, 2014 at 13:31
  • 1
    facing this kind of issue? what issue? you're still contemplating over the design part. Commented Feb 17, 2014 at 16:27
  • 1
    Let us know more about your concerns. At the highest level this looks fine but there is much more to being enterprise grade.
    – Rig
    Commented Feb 17, 2014 at 16:48
  • 1
    @Sam -- you missed the sarcasm there I think, SOAP is generally viewed as bloated and enterprise-worthy round these parts. Now the question of being "enterprise grade" being a good thing is also an interesting one of the sort that would get closed here. Commented Feb 18, 2014 at 20:51

2 Answers 2


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).


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

enter image description here

Class design after refactoring

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.