This post originated from an RSS feed registered with .NET Buzz
by Christian Weyer.
Original Post: PDC Talk: Indigo - Building Services (Part 1): The Fundamentals
Feed Title: Christian Weyer: Web Services & .NET
Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/cweyer/Rss.aspx
Feed Description: Philosophizing about and criticizing the brave new world ...
Oh my god, what a mass of people in this room. They actually cannot find enough seats. And is really hot ... no AC? The session starts about 7 minutes late.
Note: There are differences between M4 and what he was talking about. A Connector is for the 'SOAP dial tone': how to get SOAP messages into and out of an AppDomain.
Concepts: Messages, Services, Ports, Channels
All code runs unchanged on Indigo: ASMX, Remoting, ES, MSMQ, ... if you want.
Messages:
SOAP, SOAP, SOAP (1.1 and 1.2)
Full support of SOAP data model
Support for 'binary XML'
No reason to linearize SOAP message for in AppDomain communication - fully supported
It is all about the XML InfoSet, not necessarily angle brackets flying around.
Message object model: Message and MessageHeader classes
Body, Header members in Message - similar (really only similar to the object model in WSE 2.0)
Port and Channels:
Ports are location in network space. Rendevouz point between my code and the outside world
Ports as a factory for channels
Messages flow through a port via channels
So nothing new here - just a few simple but essential design patterns applied in Indigo
Transport channels are the first (service) or last (client) channel in a stack
Extensible channel stack (compare to Remoting architecture)
Object model: Port, IChannel, IOutputChannel, IInputChannel, IDuplexChannel, IRequestChannel, IReplyChannel (the last two for request/response pattern)
IDuplexChannel for building a 'dialog channel'
Services and Addresses:
ServiceReferences are used to identify message recipients (based on WS-Addressing), absolute URI of service + fixed headers; essential concept for Indigo
ServiceAddress for a relativr version
Map ServiceAddress to in-memory object with IService interface
Shows a demo - code won't most probably not work with the PDC build
able to specify the policies in Port.CreateListenerChannel() - e.g. RM, security, Tx, ...
Hosting:
Services can be self-hosted or activated on demand via ASP.NET
Shares activation with ASP.NET process model
.msgx files implement this (.svc in Beta 1)
PDC build somehow limited re: hosting in ASP.NET (only low level messaging apps)
But Indigo is not tied to ASP.NET and HTTP!
Service model:
Integrates ASMX, ES, Remoting
Message based and method based programming (similar to WSE) supported
First class WSDL support
Session supported (compare conceptually with HTTP session or COM+ ObjectContext)
Defining contract in a service:
Service oriented programming model; use [Service] and [ServiceMethod] attributes
Opt-In contract
Schema-based integration
Broad interop - already tested or in theory?
Several interop modes: BP 1.0 compliance mode, pure HTTP 'legacy' compliance mode, ...
You can support common assemblies between the endpoints (sharing the code assemblies betwenn the communication partners)
Code first and contract first supported
Great support for this: [ServiceContract] - can only be applied to interfaces
But did not mention tool support to generate code interface 'skeleton' from WSDL et. al. ...
You can use RPC, async or message based programming model - just what you want
.NET Remoting-like programming with [RemoteObject] approach:
No interop, CLR focused - just between two CLRs
Still MarshalByRefObject ... for the goofy internals things going on
Building a pipeline of code before sending and/or receiving messages made easy.
What to do now? Use ASMX to prepare for Indigo and leverage ES inside your services. Use .NET Remoting only if really necessary ;-)
Sidenote: The demos were not the best, sorry to say that ... somehow the talk was perhaps a bit too 'complicated' and confusing (?) for most of the people in the room. Would have been better to show it more on a 'VB level' to illustrate the SOA approach in Indigo?!
Previous Topic
