April 29, 2009 at 5:39 am
Architecturally I am a bit stuck and am hoping to get some help from the forum.
I would like to bridge between a .Net TcpListener object and SQ Server Service Broker\WCF to receive messages onto a queue and to perform subsequent downstream communication and processing. (WCF service as stepping stone if it is required)
It would seem that for both Service Broker and WCF one needs to have compatible end points on each server, in my case on the other end of the TCP/UDP line, i.e. the origin of the messages. This, in my mind means that I either have to have another SQL Server on the other end or a WCF service? I have no control over the technology at the message origin and merely recieve fixed formatted strings, according to a defined specification.
To bridge the gap, I want to keep the current TcpListener object (receiving the messages) but potentially tap into it from Service Broker/ WCF to grab the messages onto a Service Broker queue instead of an MSMQ.
Once on the Service Broker Queue, all the functionality of Service Broker becomes available and subsequent routing is facilitated within SQL Server, where I can also use the CLR for manipulation etc.
Does anyone have some pointers that can aid me in understanding the integration between Service Broker/ WCF and the .Net TcpListener class, thus crossing from .Net into SQL Server for the received messages on a messaging basis?
Your help is much appreciated.
Viewing 0 posts
You must be logged in to reply to this topic. Login to reply