Bridge to send messages to another software RRS feed

  • Question

  • Hi,

    I was ask to create a program that will recieve messages from an interface engine. These messages will be save first to an SQL Server and base on the rules in the Database this will trigger messages outbound to a web server. Can you please tell me what will be the best approach to this? 

    Here are my thoughts:

    1) I am thinking of using Windows Service or Web Service to Recieve the messages. Can you please tell me what's the difference in terms of performance? Messages will be on a big volume base on customer records.
    2) I'm planning to use C# as my Language.

    Help would be very much appreciated.

    Many Thanks in Advance.

    Friday, December 4, 2009 10:49 AM

All replies

  • What really matters for a communication performance is a communication protocol HTTP or TCP and a serialization technique you are using. Web Services in 99% of cases use HTTP protocol as underlying protocol and SOAP or REST as an uper-level protocol.
    Web Services are mainly used for cross-platform or cross-web communication. If you have intranet scenario and both client and server run on similar platforms (windows), there is not much sense in using HTTP and it is recommended to use TCP with binary serialization.

    Eventually I recommend you to use WCF, which provides you with both options, so you will be able analyze performance differences in your particular case.
    Vitaliy Liptchinsky http://dotnetframeworkplanet.blogspot.com/
    Friday, December 4, 2009 11:07 AM
  • For high load scenarios where the timing of the actual processing isn't an issue, I would recommend that you push these messages from the database to a MSMQ queue. MSMQ is asynchronous and the receiving end can process messages as fast as possible while the queue can take all of them.

    This means, for instance, that you can push 1 million messages to the queue and the server can handle them 1000 (or what ever number you set) at a time until it is done.

    As Vitaliy suggests, WCF works well for this since it got built in support for sending and receiving MSMQ messages.

    Patrik Löwendahl [C# MVP] - blog: http://blog.lowendahl.net
    Friday, December 4, 2009 11:33 AM
  • First, thank you for your quick responses. WCF sound interesting but honestly, I haven't heard about it. I have been programming windows form but never actually programmed anything about networking.

    The thing is the interface engine where I will recieve the message is still unknown because it's still under development. So I need to take that into consideration. But one thing I'm sure is it will be an XML format. Another thing I need to make it as flexible in a way that the admin will configure which port my Service will listen. So which is the best option for this? Is it the Web Service or MSMQ or Windows Service? The outbound bit is through System.Net.Mail. So basically, I will recieve the customer info from one server and send a the customer info to the other server which then send a SMS message to the customer. (Uni-Directional)

    Thanks Again.



    Friday, December 4, 2009 3:17 PM
  • ASP.NET Web services (if that is what you mean) is obsoloete, an old technology that has been replaced by WCF. WCF is how Microsoft want's us to communicate between parties in a system going forward. The interesting thing with WCF is that it can be a web service, a MSMQ queue or a binary tcp service and you don't have to decide which when developing. Everything about the transport is configured in the app.config / web.config. When it comes to configuration, WCF is the richer player.

    When you say a "windows service" I assume you mean that you build a windows service that uses a nettcplistener or similar to listen for incoming traffic? I would not recommend a solution where you build your own communication infrastructure when WCF provides everything you need for your scenario out-of-the-box.

    My recommendation would be to investigate WCF since it gives you the most flexibility when it comes to the transport choice. Also it's built around Message Orientation which gives you a nice and easy way to define a service interface that's decoupled from the service implementation (WCF uses the standard WSDL or WS-MetaDataExhcange and not .NET type information for the service interface description).

    Patrik Löwendahl [C# MVP] - blog: http://blog.lowendahl.net
    Sunday, December 6, 2009 2:04 PM
  • Hi,

    Based on the information you have shared looks like you are into Asynchronous programming requirement, i would suggest use of Messaging based soluton using MSMQ. I am not sure about your NFR and loads.

    The messages from your external interfaces will be posted to a queue an the consumed message in turn can be implemented using a workflow or basic C# programming

    Thanks and Regards Azhar Amir
    Monday, December 7, 2009 4:12 AM
  • Hi Robert

    If the message volume is "big" as you have mentioned.
    Eventually you will need the ability to monitor, report, scale and manage.
    Implementing the mentioned messaging requirements using WCF + AppFabric can help you better cater to this.
    WCF can be hosted in App Fabric (we download on IIS) which provides you OoB management, reporting, tracing functionality.
    App Fabric is currently in beta and will take slightly more than a Quarter to be released.

    If you choose WCF now for implementation, you would have extensible design.

    Check this for overview on AppFabric...http://www.infosysblogs.com/microsoft/2009/12/appfabric_earlier_dublin_veloc.html

    hope this helps.

    Monday, December 7, 2009 5:38 AM