Presentation is loading. Please wait.

Presentation is loading. Please wait.

NSERVICEBUS Inspired by: The course authored by Udi Dahan Oslo/Fagdag Espen Ekvang/Tomas Jansson 01/03/2013.

Similar presentations


Presentation on theme: "NSERVICEBUS Inspired by: The course authored by Udi Dahan Oslo/Fagdag Espen Ekvang/Tomas Jansson 01/03/2013."— Presentation transcript:

1 NSERVICEBUS Inspired by: The course authored by Udi Dahan Oslo/Fagdag Espen Ekvang/Tomas Jansson 01/03/2013

2 AGENDA 2 Intro Messaging and queues Testing SOA Saga

3 AGENDA Why NServiceBus? Fallacies of distributed computing Hello world and logging Messaging and queues Store and forward Differences from RPC Dangers of store & forward Messaging and NServiceBus Interfaces & unobtrusive Sending Handling AsA_Server, AsA_Client Oneway messaging (client) Processing messages (server) Testing Lunch SOA Publish/subscribe Saga What is it? Sagas Rock How to test a Saga If time Encryption Message mutation Authorization 3

4 INTRO 4 Fallacies of distributed computing Why NServiceBus? Bus vs. Broker Service orientation Excercises

5 FALLACIES OF DISTRIBUTED COMPUTING 5 1.The network is reliable 2.Latency isn’t a problem 3.Bandwidth isn’t a problem 4.The network is secure 5.The topology won’t change 6.The administrator will know what to do 7.Transport cost isn’t a problem 8.The network is homogeneous Cant’ assume WHEN the message will arrive, IF AT ALL

6 WHY NSERVICEBUS 6 1.The network is reliable 2.Latency isn’t a problem 3.Bandwidth isn’t a problem 4.The network is secure 5.The topology won’t change 6.The administrator will know what to do 7.Transport cost isn’t a problem 8.The network is homogeneous NServiceBus addresses the first five directly The most developer-friendly service bus for SOA on.NET

7 BUS VS. BROKER 7 Buss.dll App Buss.dll App Buss.dll App Broker Bus is not necessarily physically separate Simpler; no routing or service fail over No single point of failure

8 TENETS OF SERVICE ORIENTATION 8 Services are autonomous Share contract & schema, not class or type Boundaries are explicit Compatibitility is base on Policy

9 LAYERS & COUPLING 9 UI BL DAL DB SalesShipping CRM Tight coupling Loose coupling Referential Integrity Reintroduces coupling

10 WHEN CAN I WRITE SOME CODE? 10 Getting started New class library Install-Package NServiceBus.Host Logging NServiceBus uses log4net, you can configure logging in app.config Default output is console

11 EXERCISES 11 H ELLO W ORLD L OGGING

12 MESSAGING AND QUEUES 12 Store & forward Dangers of store & forward Request/Response Messaging and NServiceBus Exercises

13 S ERVER STORE & FORWARD 13 MSMQ O UTGOING I NCOMING C LIENT MSMQ O UTGOING I NCOMING Store & Forward writes to disk Resilient in the face of failures

14 DANGERS OF STORE & FORWARD 14 If target is offline for an extended period of timemessages can fill up the disk Can cause a server to crash Especially problematic in B2B integration 1 MB/message, 100 message/sec = 6GB/minute Solution – discard messages after a while Use [TimeToBeReceived("00:01:00")] on the message definition

15 REQUEST/RESPONSE 15 S ERVER MSMQ O UTGOING I NCOMING C LIENT MSMQ O UTGOING I NCOMING Client can’t assume when a response will arrive, if at all Equivalent to 2 one-way messages

16 REQUEST/RESPONSE 16 Message is sent from the server to the client’s queue If the client is offline, message sits in the server machine’s outgoing queue Client is not blocked until response arrives If two requests were sent, responses may arrive out of order

17 WARNING! THIS IS NOT RPC 17 Do NOT try to implement regular request/response patterns on top of messaging The client should be designed so that it can continue operating if a response never comes Differences from RPC RPC is easy to code After invoking a web service Next line of code assumes we’ve got a response RPC problems Can’t reason about the time between one line of code and another Messaging makes this all explicit

18 MESSAGING AND NSERVICEBUS 18 S ERVER MSMQ O UTGOING I NCOMING C LIENT MSMQ O UTGOING I NCOMING Transaction

19 DEFINE A MESSAGE 19 Preferably inherit from IEvent or ICommand Use IMessage when replying using Bus.Reply() Also possible to define your own convention Configure.DefiningMessagesAs(t=>MyOwnConvention(t)) Add properties like a regular class/interface Keep contract definintions in their own assembly/project public class MyEvent: IEvent {}

20 INSTANTIATE A MESSAGE 20 var myMessage = new MyMessage(); var myMessage = Bus.CreateInstance ();

21 SEND A MESSAGE 21 Bus.Send(messageObject); Can instantiate and send together (useful for interfaces): Bus.Send ((message) => { message.Prop1 = value1; message.Prop2 = value2; });

22 SPECIFY DESTINATION 22 1.Bus.Send(destination, messages); Requires that application manages routing 2.Configure destination for message type. In, under specify one of the following: - - 3.Specify destination using - QueueName@ServerName, or - Just QueueName for the same machine

23 HANDLE A MESSAGE 23 Write a class that implements IHandleMessages where T is a message type public class MyHandler : IHandleMessages { public void Handle(MyMessage message) { } Remember to specify in, under one of the following: - -

24 CONFIGURING AN ENDPOINT 24 When configuring an endpoint inherit from 1.Using AsA_Client will - use non-transactional MsmqTransport - purge its queue of messages on startup - processes messages using its own permissions, not those of the message sender 2.Using AsA_Server will - use transactional MsmqTransport - not purge its queue of messages on startup, hence fault-tolerant - processes messages using the permissions of the sender (impersonation) 3.Using AsA_Publisher will - extends AsA_Server - indicates to the infrastructure that a storage for subscription request is to be set up

25 EXERCISES 25 O NE - WAY M ESSAGING ( CLIENT ) P ROCESSING M ESSAGES ( SERVER ) E XCEPTIONS

26 UNIT TESTING MESSAGE HANDLERS 26 Available from NuGet using Install-Package NServiceBus.Testing Provides the ability to set expectations around how message handlers handle messages Expect: Send, Reply, Publish, etc... Test.Initialize(); Test.Handler ().ExpectPublish (message => message.Prop1 == value1).OnMessage (someEvent => { someEvent.Prop1 = inputValue1; });

27 EXERCISE 27 U NIT T ESTING

28 SAGA 28 Definition Saga declaration Saga ending Saga testing Exercise

29 SAGA - DEFINITION 29 A Saga: Is a pattern for implementing long-lived transaction by using a series of shorter transactions Holds relevant state to needed to process mulitple messages in a ”saga entity” Are initiated by a message (event/command)

30 SAGA - DECLARATION 30 public class MyPolicy : Saga, IAmStartedByMessages, IHandleMessages { public void Handle(MyMessage1 order) public void Handle(MyMessage2 order) } Methods are like regular message handling logic Sagas can be started by multiple messages (IAmStartedByMessages ) First messages should start saga, following messages should be processed by the same one

31 SAGA – DECLARATION CONT. 31 public class MyPolicyData : ISagaEntity { public Guid Id { get; set; } public string Originator { get; set; } public string OriginalMessageId { get; set; } }

32 ENDING A SAGA 32 MarkAsComplete(); Can call this from any method Causes the saga to be deleted Any data that you want retained should be sent on (or published) via a message

33 UNIT TESTING A SAGA 33 Test.Saga ().ExpectPublish (/* check values */).ExpectSend (/* check values */).ExpectReplyToOriginator (/* check values */).When(saga => saga.Handle(myMessage)); /* check values */ message => return(message.Data == someValue);

34 EXERCISE - SAGAS ROCK 34

35 EXTRA EXERCISES 35 T IMEOUT C USTOM XML N AMESPACE C ONFIGURABLE ROUTING D EPENDENCY I NJECTION W EB - APP H OSTING F ULL D UPLEX D ISTRIBUTION GROUP EXERCISE


Download ppt "NSERVICEBUS Inspired by: The course authored by Udi Dahan Oslo/Fagdag Espen Ekvang/Tomas Jansson 01/03/2013."

Similar presentations


Ads by Google