Why ServiceWire

ServiceWire aims to simplify .NET process to .NET process communication. With minimal code beyond your interface and implementation, you can make your .NET process communicate with another .NET process with very high reliability and performance with minimal overhead.

ServiceWire Simplicity

The ServiceWire library aims to achieve a much narrower set features to assure simplicity and optimal utility for the much narrower use cases for which it is designed.

• Homogeneous communication -- .NET process to .NET process
• Fast transport over TCP/IP sockets or Named Pipes
  • TCP/IP for crossing machine boundaries - you choose the IP address and port
  • Named Pipes for process-to-process on the same machine
• Efficient proprietary binary serialization
• .NET simplicity
  • client calls methods on interface
  • execution occurs on server

ServiceWire Use Cases

• .NET services behind the firewall
  • Distributed shared caching
  • Business intelligence processing services
  • Long running, multi-process analysis systems
• .NET UI communication with background Windows Service
  • Windows Service provides constant processing (server)
  • UI is separate Windows application (client)

Complexities of Common Service Libraries

ServiceWire hopes to avoid many of the complexities and the overhead of common service libraries such as WCF, ASP.NET Web API, ServiceStack. While wildly popular, these support a multitude of features and options, often creating significant overhead and presenting developers with a steep learning curve and often challenging configuration and deployment scenarios. Here are a few of these:

• HTTP and binary transport
• SOAP, HTTP REST and proprietary binary protocols
• Code generated and dynamic clients
• XML and JSON and proprietary serialization
• RPC and message style operations
• Multiple security schemes
• Heterogeneous client platforms
• Complex and confusing configuration