Particular Service Platform Documentation

ServiceControl and ServicePulse use standards-based authentication via OpenID Connect (OIDC). When enabled, users must authenticate through an identity provider (IdP) to access ServicePulse, and all API calls to ServiceControl require a valid JSON Web Token (JWT).

Critical Requirements:

• HTTPS is mandatory: Authentication requires TLS to prevent tokens from being transmitted in plain text.
• Default State: Authentication is disabled by default; the platform is accessible without credentials until configured.
• Configuration Flow: Authentication is configured on ServiceControl. ServicePulse retrieves these settings from ServiceControl at startup to handle the sign-in flow automatically.

The NServiceBus Quickstart solution mimics a retail system to demonstrate asynchronous messaging patterns. It consists of five projects:

• ClientUI: A web application that serves as the system entry point. It sends a PlaceOrder command to the Sales endpoint.
• Sales: A console application that processes the PlaceOrder command and publishes an OrderPlaced event.
• Billing: A console application that subscribes to and processes the OrderPlaced event.
• Messages: A shared assembly containing the class definitions for all messages used across endpoints.
• PlatformLauncher: A project demonstrating the Particular Service Platform (initially commented out).

This architecture demonstrates the publish-subscribe pattern, allowing the Billing component to remain decoupled from the Sales component.

NServiceBus provides four transaction modes to manage the consistency between receiving messages, updating user data, and sending outgoing messages. The choice of mode involves a trade-off between consistency, reliability, and performance.

• Transaction scope (Distributed transaction): Strongest guarantees; uses distributed transactions across transport and database.
• Sends atomic with Receive: Outgoing messages are committed or rolled back atomically with the receive operation, preventing 'ghost messages'.
• Receive Only: Guarantees the message is not lost from the queue until successfully processed, but does not guarantee atomicity for outgoing messages.
• Unreliable (Transactions Disabled): No transactional guarantees; used for maximum performance.

Callbacks allow developers to use messaging behind a synchronous API. This is primarily used when introducing messaging to existing synchronous web or WCF applications to allow a gradual transition.

Critical Constraints:

• Do not call callback APIs from inside a Handle method in an IHandleMessages<T> class to avoid deadlocks.
• Data Loss Risk: Callbacks are held in memory and do not survive process restarts (e.g., crashes or IIS recycles). Use callbacks only when the returned data is not business-critical. For fault-tolerant requirements, use request/response with a message handler or Sagas.
• Response Limit: If a server returns multiple responses, only the first response invokes the callback to prevent memory leaks.

The NServiceBus Gateway provides durable fire-and-forget messaging across physically separated sites (distinct physical locations). It is intended for 'logically different sites'—where sites have different responsibilities or behaviors—and requires the use of explicit messages for cross-site communication.

Key characteristics:

• Supports automatic de-duplication and retries.
• Does NOT support the publish-subscribe pattern.
• Should NOT be used as a disaster recovery mechanism for exact replicas of the same application.
• Useful when VPNs are unavailable due to security, bandwidth, or latency constraints.
• Features include SSL transport encryption, Databus for large payloads, and HTTP/HTTPS channel implementations.