2. Why use a service bus? Definition “a software architecture construct which provides fundamental services for complex architectures via an event-driven and standards-based messaging engine (the bus).” – Wikipedia Building Systems vs. Applications System Application
3. The 8 fallacies of distributed computing The network is reliable Latency isn’t a problem Bandwidth isn’t a problem The network is secure The topology won’t change The administrator will know what to do Transport cost isn’t a problem The network is homogeneous Deutsch ‘94, Gosling ‘97
4. Coupling Platform Interoperability matters( Fallacy #8 ) Proprietary vs. Standard protocols Schema & Contract – XML Spatial Server A relies on Server B Can communication continue? Store & Forward Temporal The processing of B affects that of A Request/Response Asynchronous Messaging Linux Windows RPC
5. Scalability & Flexibility Flexibility What about upgrades? What about virtualization? Scalability Scaling Up vs. Out – don’t get stuck with one option The Grid – work distribution
6. Messaging to the Rescue! Communication between services and Endpoints is described by message patterns Durable Flexible Unidirectional – non-blocking Less coupling NServiceBus provides several messaging patterns out of the box, but allows for the composition and/or creation of new patterns
7. Example Rollback Rollback Transaction Queue Order DB Call 1 of 3 Call 2 of 3 App Order is back in the queue
21. Publish & Subscribe 5 Subscription Storage Publisher Subscriber Bus Bus Subscriber Subscriber Bus Bus Bus.Publish(), Bus.Subscribe(), Bus.Unsubscribe()
25. Distributor 2 Work Management Distributor Worker Bus Worker Worker Bus Bus
26. Distributor Config <appSettings> <add key="NumberOfWorkerThreads" value="1"/> <!-- queue that the distributor process reads and feeds to workers --> <add key="DataInputQueue" value="nservicebus_distributor_data_bus"/> <!--queue that manages work distribution --> <add key="ControlInputQueue“ value="nservicebus_distributor_control_bus"/> <!-- errors --> <add key="ErrorQueue" value="nservicebus_error"/> <!-- queue that maintains the state(availability) of the workers --> <add key="StorageQueue" value="nservicebus_distributor_storage"/> <!-- relevant for a Serialization of "interfaces" or "xml" --> <add key="NameSpace" value="http://www.MySite.com"/> <add key="Serialization" value="xml"/> <!-- can be either "xml", or "binary" --> </appSettings>
31. Summary The Bus architectural style typically prompts more questions What happens if communication fails? How long can it take for a process to complete? What is my process dependent on and what depends on my process? Is ok to lose an order(or other entity)? Is this truly a domain event? NServiceBus provides the plumbing, you must provide the System
32. Thank you Adam Fyles Solution Architect AdamFyles.blogspot.com GitHub.com/afyles NServiceBus.com Credits: Udi Dahan, NSB Author
Notas del editor
As long as there is a network, it will fail. What if someone digs up the line? True story…LAN vs. WAN vs. Internet, 1000x slower than in memory accessData grows with bandwidth and usually outpaces itCan’t be 100% safe, there will always be somethingServer moves, subnet changes, switch upgradesMany admins doing a ton of different work(patches, upgrades, moves) will not know what to doSerialization and the ongoing cost of hardwareWindows/Unix/Linux/.NET/Java/C++