.NET Full Trust: provides developers with a level of flexibility in
Windows Azure that removes limitations on .NET libraries which require
full trust (including .NET Services). .NET Full Trust, via spawning
processes and P/Invoke, also allows developers to leverage existing
investments in native code or legacy components that they will now be
able to invoke on Windows Azure.
FastCGI: allows developers to deploy and run web applications written with 3rd party programming languages such as PHP and Ruby. This provides developers using non-Microsoft languages the ability to take advantage of scalability on Windows Azure. This includes enabling the IIS URL Rewrite Module, cool!
Geo-location: provides developers with the ability to specify a location for their applications and data to build responsive services with lower network latency as well as the capability to meet location-based regulatory and legal requirements.
More details on Full Trust support here. Interesting cloud times ahead... but some data centers outside of the US are highly needed :) Be sure to check out the download information for the Windows Azure SDK and Visual Studio tools.
Agreed: there has never been a really good relationship - let's not even start talking about friendship - between Germans and Brits. Let's forget about this for a while... working together with an industry luminary like Richard Blewett is more than I could ever wish.
Luckily enough, Richard joined thinktecture this week as a high-class consultant - welcome! Working with Rich (subscribe to his blog here) is surely going to be a lot of fun.
I am really keen on what will be presented at PDC in LA when looking at news like this. To say the least, impressive. The time for "vaporware" is definitely over. People, we want and our customers need facts. Period.
Sorry, we have strange problems when people want to comment on our posts. If you have submitted a comment in the last few weeks and it did not show up here, feel free to contact me. Sorry again.
Man, I really cannot get that sound and chorus out of my head. For the third time within three days I heard at least Don Box sing "All we are saying, is give SOAP a chance" (the first two gigs were together with the Band on the Runtime). Today he and some of the Indigo team chimed into the song together with the crowd attending the Indigo panel discussion at PDC. Especially Doug was very excited about that and thought that a large German non-musician could help in singing ... kinda.
No, nothing is dead, nothing is deprecated - it is a matter of what to use when and why ... and how! Please burn this into your head. The central messsage again and again regarding the new features and cool things in Indigo: .NET Remoting will keep working from now till the end of time - nothing will be deprecated ASMX will keep working from now till the end of time - nothing will be deprecated .NET Enterprise Services will keep working from now till the end of time - nothing will be deprecated
It is just that the productivity sweetspot is the SOA thing - and this is what Indigo is for.
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?!
Combine best of web, best of Windows developer experience
Parts of the demos show functionality that has been around for years with Flash, PDFand the like. Will there be a major platform lock-in in the future (read: it only works on Longhorn and above)?
XAML:
- one-to-one correspondance with object model
- enables interoperation between UI authoring and dev tools
- 'just' a persistence format for .NET classes (majorly UI related)
- code behind for Windows apps
Puh - it is a hard talk to listen to. Very introductory level, not much details. Quit just 15 minutes before the end ...
