Federated and Event Driven Architecture

Event Driven Architecture (EDA): System components interact with each other by producing, detecting and reacting to events.

Event-driven APIs differ from conventional REST APIs, offering improved scalability, strong service decoupling, reduced network traffic, and greater flexibility. Even-driven APIs need to address the challenges of monitoring, distributed tracing, security, and versioning.

Distributed, event-driven architectures are a powerful approach to building decouple long-running, high-performance, scalable systems and can use Conflict-Free Replicated Data Types (CRDTs) to provide eventual consistency.

An Event Mesh is a dynamic, interconnected network of event brokers that allows events to flow seamlessly across distributed applications, regardless of where they are deployed—on-premises, in the cloud, or at the edge.

Federated architecture allows each system to flexibly interact with other systems while remaining independent, so it can be easily extended, and individual pieces (a system) can be replaced relatively quickly.

Thoughts: Like Cross cutting concerns where you build IT runway to perform specific tasks and then call them, Federated Architecture, each system does a job so for instance, there is a standalone system that can be replaced or extended for Requesting a Room (1st system), this allows the user to reserve a room using the booking system (2nd system), this in turn calls the communication system that handles email, teams meeting with reminders (3rd system) and then calls the communication systems (n services/systems)

Events are facts; they are loosely coupled to the booking system.  This approach allows for the reuse and easy creation of highly customised business processes.

Thought: Choosing between an Event Mesh and a Federated Architecture...

Integrating Software & Data Thoughts

Problem: Systems need to communicate, the simplest is a one-way communication (Mono directional) done on a scheduled basis, the hardest is 2-way comms, in real time. 

Hypothesis: Figure out you requirement, this sounds odd but 2 way with both being the primary causes headaches.  Adding multiple systems and security at a user level makes integration more complex. 

Keep it simple figure out: 

• Apps to connects - Can be an N-to-M set of relationships 
• Direction/Parent - One way, 2 way. 
• Re-occurrence - scheduled, events, real-time. 

Your application will generally be the spoke and not the hub.  So if you are the hub the generally accepted way for SaaS is for the hub to offer an Open API and the hub controls the schedule/event to get or push the data to the hub.

Possible resolutions: 

• Central Sw that has connectors can be a good option for complex multisystem communication: https://www.codat.io
• Always understand the API's hopefully you don't need to use exports to get data but sometimes you need to fall back to this level.
• Also ensuring transactions are completed over 2 systems need to validate data is committed, use Saga or 2PC pattern.

SPMetal Jbg Presentation evening

Thank-you to everyone that came to the presentation and Singular who sponsored the event.  I enjoyed doing the 2 sessions and meeting some new SharePoint folk.

Slide decks:

Session 1 - PowerPoint SP2010 Data Access (includes the introduction to LINQ to SharePoint)
Session 2 - PowerPoint presentation on LINQ to SharePoint with the demo

I'll record the slides and if i can get the presentation to a reasonable size I'll add the downloads here - more info to follow.

Code Download:

VS2010 solution - This solution contains 3 projects with the code used for this presentation.

1. SPDemoLists - Pragmatically deploy the Customers and Order lists with a list lookup and populate the 2 lists with seed data.  Sandbox solution.
2. SPDemoUI - C# sandbox solution that contains a visual user control (web part) that allows a customer to be selected in a drop down and then display the related orders for that customer.  Additionally there is a button to delete the selected customer. 
3. SPDemonUnit - is an NUnit blank C# project setup ready to start adding unit tests.

SharePoint 2010 Johannesburg Knowledge Group Meeting Post
Event details: http://sp2010jbg.eventbrite.com/
Session summary's
Session 1
Presentation - Overview of data access in SharePoint. What are your options? Is SharePoint storage always the answer? What is LINQ to SharePoint? What is LINQ to SharePoint not good at? The 8 caveats to LINQ to SharePoint.
Session 2
Demonstrate LINQ to SharePoint 2010. Using Visual Studio creating a visual web part to perform CRUD operations on SharePoint lists.