Database Reference
In-Depth Information
Gateway messaging
There are cases for when one part of the services may be stored on one part of an organiza-
tion's LAN, while other services are stored on another LAN; the only mode of transport
that both these parts have to pass messages to NSB is through the use of an HTTP or
HTTPS tunnel.
The main purpose of the gateway is to allow you to perform the same durable fire-and-for-
get messaging that you are accustomed to with NServiceBus across physically separated
sites, where sites are locations where you run the IT infrastructure and not the websites.
The gateway only comes into play when you can't use the normal LAN-to-LAN VPN tun-
nels or internal LAN servers to communicate MSMQ to MSMQ. The purpose of the gate-
way is to create messages that communicate through HTTP, but it would be preferable to
use HTTPS to ensure that messages are secured.
In this section, we will be using the
Gateway
solution:
•
Headquarter.Messages
: This refers to the common messages for
Headquarters
,
SiteA
and
SiteB
.
•
Headquarter
: This will receive messages from
ht-
tp://localhost:25899/Headquarter/
and
ht-
tp://localhost:25899/Headquarter2/
, and send messages to
ht-
tp://localhost:25899/SiteA/
and
http://localhost:25899/
SiteB/
.
•
SiteA
: This is a project that will receive the update price information from
Headquarters
via
http://localhost:25899/SiteA/
and respond that
it was successful back to the
Headquarters
via
ht-
tp://localhost:25899/Headquarter2/
.
•
SiteB
: This is a project that will receive the update price information from
Headquarters
via
http://localhost:25899/SiteB/
.
•
WebClient
: This will have an
Index.htm
page to send a JSON script to
ht-
tp://localhost:25899/Headquarter/
.
These were run in VS2012 in Windows Server 2012 with MSMQ, DTC, NServiceBus ref-
erences, and SQL Server 2012 Express LocalDB installed.
