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 ;-)
Details following in the other talks ...
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?!
Read: PDC Talk: Indigo - Building Services (Part 1): The Fundamentals
Previous Topic
