2. Introduction
•By using the .NET 4 Framework, with the
combination of the Windows Communication
Framework (WCF), Workflow (WF), Model-
View-Controller (MVC3), Entity Frameworks
(EF4), Azure, AppFabric, and Message Queuing,
I believe that Microsoft has brought serious
competition to compete against the entire
spectrum of all other Enterprise Development
Systems.
3. Introduction 2
•Now Microsoft systems can be virtualized to
be decoupled form the hardware, be stripped
down to run minimum services for the
applications, and have many diagnostic and
management tools.
•This turns the Operating System into an
Application Server to be reckoned with from
the Application Server vendors.
•This could also creates software quality that
was never as common as it is now in the
Industry, see
4. The need for ESB
•An ESB, is a software architecture model used
for designating and implementing the
interaction and communication between
mutually interacting software applications in
Service Oriented Architecture,
http://en.wikipedia.org/wiki/Enterprise_service
_bus
5. The need for ESB
•The Bus, is the combination of software that
queues messages, routes messages and
processes messages to the correct endpoints.
•In order to do this ESB software will usually
use other frameworks that handle message
queuing and standard message queuing
mechanisms.
•For instance, NServiceBus can use RabbitMQ
or MSMQ.
6. Some benefits of ESB
•The message bus provides both
standardization and integration of messages
across an enterprise.
•A message could be sent from any endpoint,
be it a database or service, and the messages
are routed and interpreted to other services
through the bus.
•The services could be redundant as they could
come from any endpoint.
•Even though the messages could be complex
7. NServiceBus
•NServiceBus is an Open Source Enterprise
Service Bus for .Net, http://nservicebus.com/
•Commercial licenses are required based on
messages per second,
http://nservicebus.com/License.aspx
•For the basic code, it can be pulled from
https://github.com/NServiceBus/NServiceBus
8. Other Choices
•There are many ESB choices, but price and
documentation, including blogs and samples
usually drive my choice.
•For .NET, there is additionally BizTalk,
MassTransit, KeystrokeESBNet and
SimpleServiceBus.
•There are many sites like
http://en.wikipedia.org/wiki/Comparison_of_b
usiness_integration_software
9. AppFabric
•Adding a caching provider and a monitoring
service to WCF and WF creates the Microsoft
AppFabric Framework and Architecture.
•There is a special version that supports Azure.
•The Micrsoft.ServiceBus.dll and namespace
will be used to extend Service Bus helper
extensions to WCF and WF.
10. Biztalk
•Biztalk uses a Micrsoft ESB Toolkit to build ESB.
This Toolkit intergrates into Visual Studio 2010.
http://technet.microsoft.com/en-
us/library/ff699598.aspx
•NServiceBus also has modeling and Code
Snippets that integrate into Visual Studio 2010
as well, more work has been done into Visual
Studio 11.
11. Other Choices
•Even other choices include not to utilize ESBs
at all, but use other technology like Windows
Communication Foundation Workflow Services
for SOA Binding Services and MSMQ as a
message queue system to build a message
system.
•But standard Message Queue and ESB
frameworks provide the pieces that are already
built and tested.
•The downside is that you may be locked into
the technology and the roadmap that the
12. NServiceBus
•NServiceBus is an Open Source Enterprise
Service Bus for .Net, http://nservicebus.com/
•Commercial licenses are required based on
messages per second,
http://nservicebus.com/License.aspx
•For the basic code, it can be pulled from
https://github.com/NServiceBus/NServiceBus
14. Getting Started
•The benefit of using a ESB package is that it
will normally handle the messaging packages
for you, NServiceBus handles a lot of the
MSMQ and DTC complexities.
•See
http://nservicebus.com/GettingStarted.aspx ,
http://nservicebus.com/GettingStarted2.aspx
http://nservicebus.com/GettingStarted3.aspx
16. Getting Started
•You will be prompted to install NServiceBus
Studio for building NServieBus projects in
Visual Studio, this plugin is found under /tools:
18. Core Files
•There are many libraries included with
NServiceBus, some for custom configs, and
many samples to include from GitHub, but
basic 4 libraries included for almost all apps
are; log4net.dll, NServiceBus.Core.dll,
NSeviceBus.dll, and NServiceBus.Host.exe.
•NServiceBus is heavily reliant on Apache’s
log4net for default logging and the correct
version must be installed.
19. Endpoint
•Normally every NServiceBus has one Endpoint,
which is the Queue name to read or write
messages.
•If not defined, by default, the current
namespace of the project will be used. This
method is sometimes used on Servers reading
queues.
•The name will be followed by an “@” with a
servername to be server specific.
20. Endpoint
•There are different conventions and ways to
define an Endpoint, I found that this will also
depend on the version of NServiceBus being
used,
http://andreasohlund.net/2012/01/27/convent
ion-over-configuration-in-nservicebus-3-0/
21. Endpoint – FullDuplex Example
•App.config will normally define the endpoint
in the UnicastBusConfig, here we define the
Message as well in the Client:
22. Endpoint – FullDuplex Example
•Instead of using App.config, the configuration
can be programmatic by building a class using
IProviderConfiguration:
23. Endpoint from different places
•So, we could put a UnicastConfigBusConfig, for
messages and an endpoint in an App.config,
and a MessageForwardingInCaseOfConfig like
so:
24. How do the different configs come
together
•The purpose of all the configs is simply to build
an IBus instance to send or receive the
messages.
•The Bus is normally created by a Handler or
building the bus directly with an arrangement
of Builder calls.
25. A sample Builder for SendOnly
•Note : The order of which calls happen first
can change the functionality.
•This allows tighter control of the Bus.
27. Send versus Publish
•After the Bus is built with the configs and
handlers, the clients and server need to Send,
Publish or Reply to messages.
•See http://mookid.dk/oncode/archives/807 ,
NServiceBus for Dummies who want to be
Smarties for some of the differences.
28. Send with a Destination Server as
it sends
•Notice the “someserver”:
30. Start with the Builders
•We will start with Configure.With() from and a
builder type:
•The builders can be Defaultbuilder(),
AutoFacBuilder(), CastleWindsorBuilder(),
NinjectBuilder(), SpringBuilder(),
StructureMapBuilder(), and UnityBuilder().
31. Information on Builders
•These Builder Objects are the containers in
which to build the bus and configurations.
http://nservicebus.com/Containers.aspx
•First the configurations will be declared for
endpoints, transactional, type of container and
then the CreateBus() and Start() will initiate the
bus.
32. Types of Builders/Containers
•AutofacBuilder() – is the default container,
same as DefaultBuilder() , that will use internal
extensions in NServiceBus.
•CastleWindsorBuilder() – Castle Windsor is an
Inversion of Control container.
http://en.wikipedia.org/wiki/Castle_Project
•NinjectBuilder() – A Inversion of Control
container, sometimes called the ninja of
dependency injectors,
http://ninject.codeplex.com/wikipage?title=Wh
33. Types of Builders/Containers
•SpringBuilder() – A Inversion of Control
container for Spring.net.
http://www.springframework.net/
•StructureMapBuilder () – A Inversion of
Control container for StructureMap,
http://docs.structuremap.net/.
•UnityBuilder() – A Inversion of Control
container, Dependency Injection container from
Microsoft. http://msdn.microsoft.com/en-
us/library/dd203101.aspx
34. Next is normally the Serializers
•Next is normally the Serializers, this will
transfer the message as binary or xml data.
•XmlSerializer() – Serializes the objects into an
XML format, but there are limitations with the
XML serialization in NServiceBus with object
lists, Derived Objects, and arrays of objects,
http://stackoverflow.com/questions/2816895/
nservicebus-serization-issue-of-derived-types ,
the work around is to use the Binary
35. Next is normally the Serializers
•BinarySerializer() – Serializes the objects into
an binary format, and is done with the standard
.net binary serializer,
http://nservicebus.com/Performance.aspx
•JSonSerializer() – Javascript Object Notation
(JSON) format serialization, uses the
Newtonsoft.json interface,
http://json.codeplex.com/ .
36. Next is normally the Transport
•Next is normally the Transport, this is the
queuing mechanism, and in many cases will be
MSMQ.
•Transports can be created using
ISendMessages and IReceiveMessages. A
Service Broker example can be seen in
NserviceBus-Contrib that includes a Sample
https://github.com/NServiceBus/NServiceBus-
Contrib
37. Transport Types
•MsmqTransport() – This is the MSMQ
Transport mechanism commonly used, there
are many samples, see FullDuplex example.
•FtpTransport() – This is a Transport to send
messages across FTP, which has to have a
directory, username and password included for
FTP setup, see the FtpSample.
•AzureQueueMessage() – Using Storage
Queues for Azure, see the Azure examples.
38. UnicastBusConfig
•Now UnicastBus() must be defined:
•UnicastBus() tells NServiceBus to use unicast
messaging. Used out of the box, see
http://nservicebus.com/SelfHosting.aspx
•Here we have a UnicastBusConfig defining the
message and endpoint in App.config client:
39. Now for the Bus
•So far these have only been configurations and
the bus still hasn't been created, to create the
bus, CreateBus() must be used, and to start the
bus, then Start() must be used,
40. For SendOnly
•For SendOnly(), createbus and start are not
needed because not all the components are
needed from the bus.
42. Why I looked at SendOnly
•I started looking at SendOnly because Publish
was not recommended for the Web interfaces.
http://www.make-
awesome.com/2010/10/why-not-publish-
nservicebus-messages-from-a-web-application/
•Publishing requires a Subscription storage and
the messages are normally handled as
transactional events,
http://nservicebus.com/PubSubApiAndConfigu
ration.aspx
43. Subscription Storage
•If multiple machines share the same
subscription storage, then Database Storage
needs to be used, .DBSubscriptionStorage().
•The Nhibernate connection strings will need to
be defined in the App.config.
44. Subscription Storage
•If multiple machines share the same
subscription storage, then Database Storage
needs to be used, .DBSubscriptionStorage().
•The Nhibernate connection strings will need to
be defined in the App.config.
45. Subscription Storage
•If multiple machines share the same
subscription storage, then Database Storage
needs to be used, .DBSubscriptionStorage().
•The Nhibernate connection strings will need to
be defined in the App.config.
47. Installers
•In the Manufacturing and AsyncPages, there is
the Install() for the installation of endpoints
and infrastructure, such as MSMQ and
RavenDB.
•See
http://andreasohlund.net/2012/01/26/installer
s-in-nservicebus-3-0/
49. NServiceBus supports many types
of messaging Schemes
•NServiceBus supports messaging through
databases, like its native RavenDB, or SQL
Server.
•It also supports Message Queuing mechanisms
like Microsoft Message Queue and Apache’s
RabbitMQ.
50. MSMQ
•MSMQ is the Message Queuing System built
into the Microsoft Operating System since
1997.
•The Server Operating Systems, like Windows
Server 2008, offers additional features.
•See
http://en.wikipedia.org/wiki/Microsoft_Messag
e_Queuing
51. Viewing MSMQ
•It is important to administer the MSMQ
Queues when building MSMQ applications. If
the Queue is not built, the application could
error.
•The Queue will normally store its data in XML
or Binary form. XML makes the data readable
for troubleshooting.
52. Viewing MSMQ
•While there is the Visual Studio View Servers,
he MSMQ MMC, and even the Computer
Management way to view Queues.
•I still like to use IMQT to view the XML, a
commercial tool is Queue Explorer. IMQT is
http://utvecklargodis.blogspot.com/2007/03/m
smq-management-tool.html
55. Programming MSMQ
•Windows will use the System.Message
namespace to program the MessageQueue
class.
•NServiceBus offers extensions of this class as
MSMQUtilities for managing Queues and
MSMQInstallation for installing MSMQ.
•These are in the NServiceBus.Utils namespace,
found in the NServiceBus.Utils.dll.
•Code for MSMQUtilities can be found at
https://github.com/NServiceBus/NServiceBus/
56. Programming MSMQ
•Here is a small example to check if a Queue is
built, and if not build it with the Administrator
username using both System and NServiceBus
Utils for the client, the server should create its
own queue by default:
58. Unit Testing
•NServiceBus normally uses NUnit to test with
handlers that it already has built in for Sends
and Publish. Nunit can be found at
http://www.nunit.org/
•The code for the Handlers can be found at
https://github.com/NServiceBus/NServiceBus/
blob/master/src/testing/Handler.cs
59. Unit Testing
•To test Nunit in Visual Studio, you will likley
need to install a plugin like TestDriven.Net,
Resharper, or Ncoverage., and the nunit
framework will have to be installed.
60. Handlers
•Here’s what a typical Test Handler looks like to
test if the message and header is validated:
61. MOQ
•Another choice besides using the NServiceBus
custom handlers is to use MOQ.
•MOQ is used to mockup a bus, MOQ came
from http://code.google.com/p/moq/
•There are many links for doing this, one with
some sample test code can be found at
http://pastebin.com/CSrN6fR1
63. Installing NServiceBus as Service
•It was mentioned earlier that
NServiceBus.Host.Exe is one of the 4 files to
always be included with NServiceBus.
•This is the file used for running NServiceBus
applications that are non-Console based.
•This file is used for installing, running and
debugging NServiceBus applications.
•See http://nservicebus.com/GenericHost.aspx
65. NServiceBus.Host.exe commands
•A service can be created at the command line
by using NServiceBus.Host.exe /install /serviceName:MyServer.dll
/displayName:"My Super Duper service" /description:"My server
installed by NService Magic”
•See
http://prashantbrall.wordpress.com/tag/nservi
cebus/ for further details on doing this.