NServiceBus
Upcoming SlideShare
Loading in...5
×
 

NServiceBus

on

  • 2,791 views

Notes on NServiceBus

Notes on NServiceBus

Statistics

Views

Total Views
2,791
Views on SlideShare
2,788
Embed Views
3

Actions

Likes
1
Downloads
77
Comments
1

3 Embeds 3

http://www.slashdocs.com 1
https://www.linkedin.com 1
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Very nice and detailed presentation and thanks for putting my blog reference in your slides.

    -Prashant Brall
    http://prashantbrall.wordpress.com/tag/nservicebus/
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

NServiceBus NServiceBus Presentation Transcript

  • NSERVICEBUS   Rich  Helton   June  14,  2012  
  • Introduc6on  •  By  using  the  .NET  4  Framework,  with  the   combina6on  of  the  Windows  Communica6on   Framework  (WCF),  Workflow  (WF),  Model-­‐ View-­‐Controller  (MVC3),  En6ty  Frameworks   (EF4),  Azure,  AppFabric,  and  Message   Queuing,  I  believe  that  MicrosoT  has  brought   serious  compe66on  to  compete  against  the   en6re  spectrum  of  all  other  Enterprise   Development  Systems.      
  • Introduc6on  2  •  Now  MicrosoT  systems  can  be  virtualized  to  be   decoupled  form  the  hardware,  be  stripped  down   to  run  minimum  services  for  the  applica6ons,   and  have  many  diagnos6c  and  management   tools.      •  This  turns  the  Opera6ng  System  into  an   Applica6on  Server  to  be  reckoned  with  from  the   Applica6on  Server  vendors.  •  This  could  also  creates  soTware  quality  that  was   never  as  common  as  it  is  now  in  the  Industry,   see   hYp://en.wikipedia.org/wiki/SoTware_quality     View slide
  • The  need  for  ESB  •  An  ESB,  is  a  soTware  architecture  model  used   for  designa6ng  and  implemen6ng  the   interac6on  and  communica6on  between   mutually  interac6ng  soTware  applica6ons  in   Service  Oriented  Architecture,   hYp://en.wikipedia.org/wiki/ Enterprise_service_bus     View slide
  • The  need  for  ESB  •  The  Bus,  is  the  combina6on  of  soTware  that   queues  messages,  routes  messages  and   processes  messages  to  the  correct  endpoints.    •  In  order  to  do  this  ESB  soTware  will  usually   use  other  frameworks  that  handle  message   queuing  and  standard  message  queuing   mechanisms.    •  For  instance,  NServiceBus  can  use  RabbitMQ   or  MSMQ.    
  • Some  benefits  of  ESB  •  The  message  bus  provides  both  standardiza6on  and   integra6on  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  and   coming  from  endpoints  that  are  different,  such  as  a   mainframe  to  SQL  database,  the  bus  is  meant  to   translate  their  usage.    
  • NServiceBus  •  NServiceBus  is  an  Open  Source  Enterprise   Service  Bus  for  .Net,  hYp://nservicebus.com/    •  Commercial  licenses  are  required  based  on   messages  per  second,   hYp://nservicebus.com/License.aspx    •  For  the  basic  code,  it  can  be  pulled  from   hYps://github.com/NServiceBus/NServiceBus    
  • Other  Choices  •  There  are  many  ESB  choices,  but  price  and   documenta6on,  including  blogs  and  samples   usually  drive  my  choice.      •  For  .NET,  there  is  addi6onally  BizTalk,   MassTransit,  KeystrokeESBNet  and   SimpleServiceBus.    •  There  are  many  sites  like   hYp://en.wikipedia.org/wiki/ Comparison_of_business_integra6on_soTware    
  • AppFabric  •  Adding  a  caching  provider  and  a  monitoring   service  to  WCF  and  WF  creates  the  MicrosoT   AppFabric  Framework  and  Architecture.  •  There  is  a  special  version  that  supports  Azure.  •  The  MicrsoT.ServiceBus.dll  and  namespace   will  be  used  to  extend  Service  Bus  helper   extensions  to  WCF  and  WF.  
  • Biztalk  •  Biztalk  uses  a  MicrsoT  ESB  Toolkit  to  build   ESB.    This  Toolkit  intergrates  into  Visual   Studio  2010.   hYp://technet.microsoT.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.    
  • Other  Choices  •  Even  other  choices  include  not  to  u6lize  ESBs  at   all,  but  use  other  technology  like  Windows   Communica6on  Founda6on  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   framework  uses.      
  • NServiceBus  •  NServiceBus  is  an  Open  Source  Enterprise   Service  Bus  for  .Net,  hYp://nservicebus.com/    •  Commercial  licenses  are  required  based  on   messages  per  second,   hYp://nservicebus.com/License.aspx    •  For  the  basic  code,  it  can  be  pulled  from   hYps://github.com/NServiceBus/NServiceBus    
  • NServiceBus-­‐Intro  
  • Gegng  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  complexi6es.    •  See   hYp://nservicebus.com/GegngStarted.aspx  ,  hYp://nservicebus.com/GegngStarted2.aspx  hYp://nservicebus.com/GegngStarted3.aspx  
  • Gegng  Started  •  The  installa6on  is  usually  just  running  the   RunMeFirst.bat  file  with  the  correct   Administrator  permissions.    
  • Gegng  Started  •  You  will  be  prompted  to  install  NServiceBus   Studio  for  building  NServieBus  projects  in   Visual  Studio,  this  plugin  is  found  under  / tools:  
  • NServiceBusStudio  •  See   hYp://www.i-­‐m-­‐code.com/blog/blog/2012/03/15/ nservicebus-­‐vs-­‐modeling-­‐tools/  •  Also  an  example  on     hYp://nservicebus.com/GegngStarted.aspx    
  • 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.    
  • 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  some6mes  used  on  Servers   reading  queues.    •  The  name  will  be  followed  by  an  “@”  with  a   servername  to  be  server  specific.    
  • Endpoint  •  There  are  different  conven6ons  and  ways  to   define  an  Endpoint,  I  found  that  this  will  also   depend  on  the  version  of  NServiceBus  being   used,  hYp://andreasohlund.net/2012/01/27/ conven6on-­‐over-­‐configura6on-­‐in-­‐ nservicebus-­‐3-­‐0/  
  • Endpoint  –  FullDuplex  Example  •  App.config  will  normally  define  the  endpoint   in  the  UnicastBusConfig,  here  we  define  the   Message  as  well  in  the  Client:  
  • Endpoint  –  FullDuplex  Example  •  Instead  of  using  App.config,  the  configura6on   can  be  programma6c  by  building  a  class  using   IProviderConfigura6on:  
  • Endpoint  from  different  places  •  So,  we  could  put  a  UnicastConfigBusConfig,   for  messages  and  an  endpoint  in  an   App.config,  and  a   MessageForwardingInCaseOfConfig  like  so:  
  • 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.    
  • A  sample  Builder  for  SendOnly  •  Note  :  The  order  of  which  calls  happen  first   can  change  the  func6onality.    •  This  allows  6ghter  control  of  the  Bus.    
  • A  sample  Handler  for  a  Reply  
  • Send  versus  Publish  •  ATer  the  Bus  is  built  with  the  configs  and   handlers,  the  clients  and  server  need  to  Send,   Publish  or  Reply  to  messages.    •  See  hYp://mookid.dk/oncode/archives/807  ,   NServiceBus  for  Dummies  who  want  to  be   Smar6es  for  some  of  the  differences.      
  • Send  with  a  Des6na6on  Server  as  it  sends  •  No6ce  the  “someserver”:  
  • Building  the  IBus  
  • 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().    
  • Informa6on  on  Builders  •  These  Builder  Objects  are  the  containers  in   which  to  build  the  bus  and  configura6ons.   hYp://nservicebus.com/Containers.aspx    •  First  the  configura6ons  will  be  declared  for   endpoints,  transac6onal,  type  of  container   and  then  the  CreateBus()  and  Start()  will   ini6ate  the  bus.        
  • 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.   hYp://en.wikipedia.org/wiki/Castle_Project    •  NinjectBuilder()  –  A  Inversion  of  Control   container,    some6mes  called  the  ninja  of   dependency  injectors,   hYp://ninject.codeplex.com/wikipage? 6tle=What%20Is%20Ninject?    
  • Types  of  Builders/Containers  •  SpringBuilder()  –  A  Inversion  of  Control   container  for  Spring.net.   hYp://www.springframework.net/    •  StructureMapBuilder  ()  –  A  Inversion  of  Control   container  for  StructureMap,   hYp://docs.structuremap.net/.    •  UnityBuilder()  –  A  Inversion  of  Control  container,   Dependency  Injec6on  container  from  MicrosoT.   hYp://msdn.microsoT.com/en-­‐us/library/ dd203101.aspx  
  • 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  limita6ons  with  the  XML   serializa6on  in  NServiceBus  with  object  lists,  Derived   Objects,  and  arrays  of  objects,   hYp://stackoverflow.com/ques6ons/2816895/ nservicebus-­‐seriza6on-­‐issue-­‐of-­‐derived-­‐types  ,  the   work  around  is  to  use  the  Binary  serializa6on  or  to   change  the  objects  to  account  for  these  issues.    
  • Next  is  normally  the  Serializers  •  BinarySerializer()  –  Serializes  the  objects  into   an  binary  format,  and  is  done  with  the   standard  .net  binary  serializer,   hYp://nservicebus.com/Performance.aspx    •  JSonSerializer()  –  Javascript  Object  Nota6on   (JSON)  format  serializa6on,  uses  the   NewtonsoT.json  interface,   hYp://json.codeplex.com/  .  
  • 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   hYps://github.com/NServiceBus/NServiceBus-­‐ Contrib      
  • 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.    
  • UnicastBusConfig  •  Now  UnicastBus()  must  be  defined:  •  UnicastBus()  tells  NServiceBus  to  use  unicast   messaging.    Used  out  of  the  box,  see   hYp://nservicebus.com/SelfHos6ng.aspx  •  Here  we  have  a  UnicastBusConfig  defining   the  message  and  endpoint  in  App.config   client:  
  • Now  for  the  Bus  •  So  far  these  have  only  been  configura6ons   and  the  bus  s6ll  hasnt  been  created,  to   create  the  bus,  CreateBus()  must  be  used,   and  to  start  the  bus,  then  Start()  must  be   used,    
  • For  SendOnly  •  For  SendOnly(),  createbus  and  start  are  not   needed  because  not  all  the  components  are   needed  from  the  bus.    
  • Publish  with  Installers  
  • Why  I  looked  at  SendOnly  •  I  started  looking  at  SendOnly  because  Publish   was  not  recommended  for  the  Web   interfaces.   hYp://www.make-­‐awesome.com/2010/10/ why-­‐not-­‐publish-­‐nservicebus-­‐messages-­‐from-­‐ a-­‐web-­‐applica6on/    •  Publishing  requires  a  Subscrip6on  storage   and  the  messages  are  normally  handled  as   transac6onal  events,   hYp://nservicebus.com/ PubSubApiAndConfigura6on.aspx      
  • Subscrip6on  Storage  •  If  mul6ple  machines  share  the  same   subscrip6on  storage,  then  Database  Storage   needs  to  be  used,  .DBSubscrip6onStorage().  •  The  Nhibernate  connec6on  strings  will  need   to  be  defined  in  the  App.config.    
  • Subscrip6on  Storage  •  If  mul6ple  machines  share  the  same   subscrip6on  storage,  then  Database  Storage   needs  to  be  used,  .DBSubscrip6onStorage().  •  The  Nhibernate  connec6on  strings  will  need   to  be  defined  in  the  App.config.    
  • Subscrip6on  Storage  •  If  mul6ple  machines  share  the  same   subscrip6on  storage,  then  Database  Storage   needs  to  be  used,  .DBSubscrip6onStorage().  •  The  Nhibernate  connec6on  strings  will  need   to  be  defined  in  the  App.config.    
  • Subscrip6on  Storage  •  The  Manufacturing  Example  shows  an  MSMQ   Storage  example  and  in  memory:  
  • Installers  •  In  the  Manufacturing  and  AsyncPages,    there   is  the  Install()  for  the  installa6on  of  endpoints   and  infrastructure,  such  as  MSMQ  and   RavenDB.  •  See   hYp://andreasohlund.net/2012/01/26/ installers-­‐in-­‐nservicebus-­‐3-­‐0/    
  • MSMQ  
  • NServiceBus  supports  many  types  of  messaging  Schemes  •  NServiceBus  supports  messaging  through   databases,  like  its  na6ve  RavenDB,  or  SQL   Server.    •  It  also  supports  Message  Queuing   mechanisms  like  MicrosoT  Message  Queue   and  Apache’s  RabbitMQ.        
  • MSMQ  •  MSMQ  is  the  Message  Queuing  System  built   into  the  MicrosoT  Opera6ng  System  since   1997.  •  The  Server  Opera6ng  Systems,  like  Windows   Server  2008,  offers  addi6onal  features.    •  See   hYp://en.wikipedia.org/wiki/ MicrosoT_Message_Queuing    
  • Viewing  MSMQ  •  It  is  important  to  administer  the  MSMQ   Queues  when  building  MSMQ  applica6ons.    If   the  Queue  is  not  built,  the  applica6on  could   error.    •  The  Queue  will  normally  store  its  data  in  XML   or  Binary  form.    XML  makes  the  data  readable   for  troubleshoo6ng.    
  • Viewing  MSMQ  •  While  there  is  the  Visual  Studio  View  Servers,  he   MSMQ  MMC,  and  even  the  Computer   Management  way  to  view  Queues.  •  I  s6ll  like  to  use  IMQT  to  view  the  XML,  a   commercial  tool  is  Queue  Explorer.  IMQT  is   hYp://utvecklargodis.blogspot.com/2007/03/ msmq-­‐management-­‐tool.html      
  • Viewing  MSMQ  in  Visual  Studio  
  • Viewing  MSMQ  in  IMQT  
  • Programming  MSMQ  •  Windows  will  use  the  System.Message   namespace  to  program  the  MessageQueue   class.  •  NServiceBus  offers  extensions  of  this  class  as   MSMQU6li6es  for  managing  Queues  and   MSMQInstalla6on  for  installing  MSMQ.    •  These  are  in  the  NServiceBus.U6ls  namespace,   found  in  the  NServiceBus.U6ls.dll.    •  Code  for  MSMQU6li6es  can  be  found  at   hYps://github.com/NServiceBus/NServiceBus/ blob/master/src/u6ls/MsmqU6li6es.cs    
  • 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   U6ls  for  the  client,  the  server  should  create  its   own  queue  by  default:  
  • Unit  Tests  
  • Unit  Tes6ng  •  NServiceBus  normally  uses  NUnit  to  test  with   handlers  that  it  already  has  built  in  for  Sends   and  Publish.  Nunit  can  be  found  at   hYp://www.nunit.org/    •  The  code  for  the  Handlers  can  be  found  at   hYps://github.com/NServiceBus/ NServiceBus/blob/master/src/tes6ng/ Handler.cs    
  • Unit  Tes6ng  •  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.      
  • Handlers  •  Here’s  what  a  typical  Test  Handler  looks  like   to  test  if  the  message  and  header  is   validated:  
  • MOQ  •  Another  choice  besides  using  the   NServiceBus  custom  handlers  is  to  use  MOQ.    •  MOQ  is  used  to  mockup  a  bus,  MOQ  came   from  hYp://code.google.com/p/moq/    •  There  are  many  links  for  doing  this,  one  with   some  sample  test  code  can  be  found  at   hYp://pastebin.com/CSrN6fR1    
  • Deploying  
  • Installing  NServiceBus  as  Service  •  It  was  men6oned  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   applica6ons  that  are  non-­‐Console  based.    •  This  file  is  used  for  installing,  running  and   debugging  NServiceBus  applica6ons.    •  See  hYp://nservicebus.com/GenericHost.aspx      
  • NServiceBus.Host.exe  debug  •  NServiceBus.Host.Exe  is  needed  to  debug  the   applica6ons:  
  • 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"     /descripCon:"My  server  installed  by  NService  Magic”  •  See   hYp://prashantbrall.wordpress.com/tag/ nservicebus/  for  further  details  on  doing  this.    
  • QUESTIONS?  
  • APPENDIX