This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Indigo is NOT a finished product!– When released, it will likely look different from what you see today
Take all code examples with a big grain of salt– The specifics will change (attribute names, namespace names, etc)– However, the examples do provide a taste of what programming
Distributed objects are passé– OO dogma destroys distributed application performance and
scalabilityChatty versus Chunky interfacesStateful versus stateless objects
– Typically, nodes must share code in order to interoperate– OO proves to be an ineffective metaphor for distributed apps on
an enterprise scale
Service Oriented Architecture (SOA) is hip– But current tools favor RPC/distributed objects over SOA– Indigo provides tools to make service orientation easy
SOA characteristics– Nodes communicate through structured messages– Uses standard message formats (SOAP, WS-*) and wire protocols
(HTTP, TCP, SMTP)– Achieves platform interoperability– Nodes are deployed independently and evolve independently– Not confined to request/reply semantics (like HTTP)
Indigo supports SOA development, but also:– Can support RPC style communication ala Remoting– Can support pure messaging ala MSMQ
The Connector layer exposes 3 main objects:– A Port represents a URL named location in network space– A Message represents a SOAP message in memory– A Channel provides message I/O through the Port
Messages– Represent a SOAP message in memory– Store and provide access to headers in memory– Provide access to the body via System.Xml types (XmlReader,
[Service]public class SimpleMath { [ServiceMethod] private int Add(int n1, int n2) { return n1 + n2; } public int Subtract(int n1, int n2) { return n1 - n2; } }
Named ParamsInteropModeCommonAssemblies
Named ParamsInteropModeCommonAssemblies
[ServiceContract]public interface ISimpleMath { [ServiceMethod] int Add(int n1, int n2); }
[Service] public class SimpleMath { [ServiceMethod] private int Add(int n1, int n2) { return n1 + n2; } [ServiceMethod] public int Subtract(Message m) { ... } [ServiceMethod] public Message Multiply(Message m) { ... } [ServiceMethod(Oneway = true)] private void FireAndForget() { ... } }
Service model parses the message for the method params
Service model parses the message for the method params
Or use (Message m) signature to work on the raw message
Or use (Message m) signature to work on the raw message
Oneway property declares that a request/reply channel is not needed
Oneway property declares that a request/reply channel is not needed
Indigo also provides the RemoteObject attribute– Provides functionality similar to .NET remoting– Use to port .NET Remoting code to use the Indigo messaging layer– WSDL generation is not supported (requires assembly sharing) – Public visibility defines the remote contract
[RemoteObject] public class RemoteMath : MarshalByRefObject { public int Add(int n1, int n2) {} }
.NET 2.0 bakes an imperative transaction model– Goal: make transactional programming ubiquitous– For example: use a transaction to update an ArrayList– Defines a set of interfaces and services to make it easier to build
custom RMs
Transactions are an important part of Indigo– "Services are autonomous" assumes reliability and correctness– Indigo extends the imperative model with a declarative model (ala
Implicit Transactions in .NET 2.0Implicit Transactions in .NET 2.0static void Main() { using(TransactionScope ts = new TransactionScope(TransactionScopeOptions.Required)) { DoSubordinateWork(); // Do work on a transacted resource ts.Consistent = true; } } static void DoSubordinateWork() { using(TransactionScope ts = new TransactionScope(TransactionScopeOptions.Supported)) { // do work on a transacted resource ... ts.Consistent = true; } }
Indigo adds declarative Tx attributes – Similar to Enterprise Services– Can apply to any Service method– Service model establishes the ambient transaction
ASMX To Indigo: Client CodeASMX To Indigo: Client Code
public class MathClient { static void Main() { SimpleMath math = new SimpleMath(); int result = math.Add(5, 2); } } using System.ServiceModel; public class MathClient { static void Main() { SimpleMath math = ServiceManager.CreateProxy<SimpleMath>(); int result = math.Add(5, 2); } }
.NET Remoting To Indigo: Client Code.NET Remoting To Indigo: Client Codeusing System.Runtime.Remoting; public class Client { static void Main() { RemotingConfiguration.Configure("remote.config"); SimpleMath math = new SimpleMath(); int result = math.Add(5, 2); } } using System.ServiceModel;
public class Client { static void Main() { SimpleMath math = ServiceManager.CreateProxy<SimpleMath>(); int result = math.Add(5, 2); } }
ES To Indigo: Object CodeES To Indigo: Object Codeusing System.EnterpriseServices; [ComponentAccessControl] [Transaction(TransactionOption.Required)] public class SimpleMath : ServicedComponent { [AutoComplete] [SecurityRole("Manager")] public int Add(int n1, int n2) {} }
using System.ServiceModel; [Service] public class SimpleMath { [ServiceMethod] [TransactionScope] [SecurityRole("Manager")] public int Add(int n1, int n2) {} }
Summary Summary -- Preparing for Indigo TodayPreparing for Indigo Today
Write services using ASMX– Minimize or abstract HTTP Context access– Minimize or abstract SOAP Extensions
Use Enterprise Services/DCOM if– Performance is critical– You need ES features (distributed Tx, object pooling)– You don't mind the extra deployment hassles of DCOM
Use .NET Remoting if– You must implement custom protocols– Performance is critical and you must cross a firewall (cannot open
to DCOM)– You need cross-appdomain communication
Use MSMQ if rich messaging support is required– Use System.Messaging rather than MSMQ APIs