locked
layered design / which transport to choose where RRS feed

  • Question

  • First I need a little introduction of what we are doing, so bear with me. For our company I build a distributred architecture around a number of external systems. The external systems generally interface through a telnet connection accepting commands and return results or acks (or nacks). Typically these systems have limited resources as to for instance the number of simultanious telnet sessions that can be openend (max. 5 to 50 depending on the system). Because of the restrictions I've build a couple of pooled EnterpriseServices objects to reduce the setup time of these telnet connections and to limit the number of simultatious connections. The objects are primarily used by webservices which serve internal client applications or (internal/external) web applications and other public webservices, yielding basically a multi layered architecture:

     

    0.external system

    1.Pooled COM+ objects

    2.central core-webservices

    3.public-webservice, web applications, clients

    4.external customer clients/systems/web-browser

     

    After a year of production it has become apparent that some of the external systems are not performing very well (long or varying latency/response times). Realizing that the bulk of the requests (but not all) to the external systems can be done asynchronously I naturaly opt for a mesage queue based solution. Using pseudo-synchronuous calls whenever a direct response is needed.

     

    The question to the forum is: at what layer would message queueing make most sense? Should the clients (level 3) better talk to a queue or queues? or should the central core (web) services (2) be replaced by core -queues? or better the Enterprise Services (1) or the communication just on top of the telnet connections (0) for instance a queue per system. 

    Or a combination?

    This would the first production environment where I see use for mesage queueing, I'm pretty seasoned in Enterprise and web services (C#)

     

    Thanks for any thoughts

    theking2

    Wednesday, October 10, 2007 4:52 PM

All replies


  • The King (all hail ye)

    wow!  Not a short question at all.

    I have a few questions:

    - Why telnet services?  I'm talking instead of web services, or msmq?  Seems over complicated, unless you have a good reason?  I'd expect slower data and possible collisions on telnet, although I have to admit that I haven't used it for quite some time

    - The fact that you'd had to limit the connections to a low number rings warning bells for me immediately.  A database connection pool is defaulted to something like 100 connections, so 50 as a start point is low.

    - Have you set up performance counters for the system, to figure out where the bottleneck lies?  Could it be infrastructure, or is it definitely the application architecture?

    - Is there a reason to not use asych calls, so that your application can fire and forget, and not be sat loaded in memory, waiting for a response?  Is that just because the async calls were an after thought, or a later addition to the system?

    - Without knowing what your system does, it would be difficult to suggest much further.  But it seems to me that you would probably sit web services on top of an SOA implementation, and drop the use of all other communication techniques?  It seems over complex, but as previously stated you may have a very good reason.

    At present you're asking about which later to put a solution to a problem of which you have not fully identified.  Which layer has the problem, where is the bottleneck?  What doesn't work as quickly as you'd expect?  Can you replace one communication mechanism with another temporarily to get the two to go head to head against each other?  Are you sure that it's the communication that's the blame, and not some sort of resource blocking, or a less than ideal application architecture?

    I hope this gets you going, looking for solutions to the problems you are facing.

    Good luck,

    Martin Platt.


    Wednesday, October 10, 2007 10:58 PM
  • Congratulations - your post has been selected for an ARCast.TV Rapid Response!

    To listen to Architect MVP Udi Dahan and Ron Jacobs address your question click here


    Hope this helps,

    Ron Jacobs
    Host of ARCast.TV

    Sunday, October 14, 2007 12:43 PM
  • Thanks Matt,

     

    Your qestions are more helpful than you can imagine :-)

     

    The "external" systems I talked about are not under my control. It is "legacy" software (voice switches and other network equipement) that we can not change easily. That's why the telnet interface. It is also this equipment that offer limited (provisioning) resouces as they, more importantly, need to switch voice and data or do other network stuff. Having said that, all of them store data in, in some cases propietairy, database systems (oracle, MySQL, DBF you name it). But the manufacturers do not let us communicate directly with this data, for obvious reasons (data integrity), hence the telnet interfaces. Besides, these systems are located at various locations (countries).

     

    That sort of sets the scenes really, the rest was/is up to me. The data needs to be accesible both interactively (give me the balance of this subscriber) and batch (enter these 500 new subscribers, oh and while you're at it, give them all a voice mail access). Synchronous access was not really a problem until a recent addition to our switch-farm. With response times of up to 10 sec. this particular system cannot be used in a synchronuous way (imagine a web user waiting for a refresh of over 10 seconds) also scalability begins to become a problem. So yes, a-synchonicity, is unfortunately, an after thought. And the problem is identified to be here


    Altough COM pooling works like a breeze deploying / debugging has proven far to complicated. We are allowed zero downtime (365*24*7, world wide operation), deploying new releases of these EnterpriseService components (a topic that is not covered in any text book I've seen) has needed occasional server restart. Web services on the other hand are deployable like a breeze but do have a rather heavy overhead on the network transport (SOAP), overkill for the internal services.

     

    Sunday, October 14, 2007 1:51 PM