+ 2 - 1 | § ¶Custom attributes should be immutable
I have the implicit knowledge that each time you call GetCustomAttributes on a type, type member or whatever, the MS.NET runtime creates a new instance of each custom attribute applied to the type or type member. I say "implicit knowledge" because I haven't been able to find any document that clearly states that. So I guess I know it for my own experience.Anyway, I found that Mono catches attribute instances, so they are only created once. This is an easy and nice optimization, but if it is so nice and so easy, why doesn't MS.NET implement it in that way?
I think that the reason is that custom attributes are metadata, and metadata should not change at run time. In MS.NET, you can get a custom attribute of a type and change its properties, but if you later get the custom attribute again, you'll get an attribute with the original values. So you are not modifying metadata, you are just modifying a local representation of metadata.
On the other hand, if attribute instances are cached, modifications to that attributes will be in fact modifications to the metadata, since you'll always get the same attribute instance with all changes in it. That's not good. Metadata should be immutable.
+ 2 - 1 | § ¶Remoting is now configurable
I finished the work that Jaime Anguiano started in RemotingConfiguration and now Mono supports configuration of channels and objects using configuration files. I also updated machine.config in CVS, so it has now the default configuration.Having RemotingConfiguraiton working, it hasn't been too difficult to add support for remote object hosting in XSP. You can now drop a dll that implements a remote object in the bin directory of XSP, add a system.runtime.remoting configuration section in web.config registering an http channel and a type, and you are done.
With all this, Remoting is now almost feature complete.
+ 2 - 1 | § ¶About Indigo
At the PDC, I was in charge of learning what was Indigo about, so I went to all Indigo sessions. Most of Don Box's sessions where more about philosopy (justifying MS's shift to the SOA model) than about technology (just have a look at his slides to see what I mean), but quite interesting anyway. Other sessions by Doug Purdy and Steve Swartz where more technical and more useful for understanding Indigo's architecture.The first thing to say about Indigo is that it does not contain revolutionary technology. It just takes the best of ASMX, WSE, Remoting, Messaging and Enterprise Services to create a new framework for building enterprise applications based on a Service Oriented Architecture model.
However, the great value of Indigo is that it integrates in a coherent way all those diverse technologies, by providing a common communication stack, common security features, transaction management and extension mechanisms.
New architecture and new features
The basic architectural elements of Indigo are messages, services, channels and ports. Messages can flow between clients and services using channels. A port is a common entry point for a set of services. It defines a base URI and works as a channel factory, since a service published in a port can be accessed by using different channels (when a first message is received for a service, a new channel is created, based on the requirements of the client and the capabilities of the service). Indigo provides several communication channels, such as HTTP and TCP.
All this infrastructure shapes a kind of "message bus" optimized to provide the best performance in several scenarios. For example, in an Indigo to Indigo communication scenario there is no need to create SOAP message. A proprietary binary format will be faster in this case.
Indigo provides support for web services, remoting and messaging on top of this message bus. The target of a message can be a web service (implemented in a similar way as asmx WS), a remote object (remote classes must be marked with a new RemoteObject attribute), or it can be a method of a class (this method will receive the raw message and can do whatever it wants with it).
There is a new XML serialization framework. The new XmlFormatter is much more flexible: it can serialize private classes and private members, provides serialization support for corlib types such as hashtable, and provides support for loosely coupled or tightly coupled type serialization. The framework also provides a new XML binary reader/writer which will be used for internal communication scenarios.
Indigo introduces a new Transaction framework. All transaction management can now be done using managed interfaces, so virtually any object can be part of a transaction (for example, an ArrayList could be included in a transaction scope). There is still some DTC dependency, but it is now an internal dependency. DTC will be used only when strictly necessary, so the new transaction framework will be faster. Three levels of transaction control are supported: manual (by using TransactionManager and related interfaces), implicit (by defining transaction scopes in the code) and declarative (using attributes, like in old Enterprise Services). Part of this new transaction framework (manual and implicit transactions) will be released in Whidbey, the remaining in Indigo.
Channels can participate in transactions (transacted channel I/O). Channels can also provide different levels of reliability.
Indigo also covers security. It supports declarative security using attributes, and security profiles for defining common mechanisms of authentication, authorization, confidentiality, etc. It is possible to extend the security framework by implementing new authentication providers, authorizers and so on.
Indigo will provide a new "Web host" where it will be possible to host the services without the need of IIS (not 100% sure about how this will work).
Client proxies are now based on Transparent Proxy (or something similar to it), so calls to the methods in the client proxy are automatically transformed into messages. There is still a WSDL tool, which generates an interface instead of a class. The proxy must be created using an explicit call to a CreateProxy
Indigo infrastructure can be extended at several points. It is possible to add hooks that are called when a service is loaded or unloaded, when a message is received or sent, etc. Those hooks can be added by applying custom attributes that implement specific interfaces (such as IExtensionAddHookProvider). Indigo uses WS-Polocy instead of WSDL bindings to specify extended server capabilities and requirements.
Migration path
Indigo will be released after Whidbey but before Longhorn, so let's say in 2 years. However, some structural classes will be already present in Whidbey.
The current MS implementation of Web Services, Remoting, Messaging and Enterprise Services will still be present in the coming .NET releases, but MS will release a plan for migrating from those technologies to Indigo. On the other hand, WSE will be supported only for around 3 years from now.
Mono strategy
Generally speaking, the strategy will be to finish those technologies for which there is work in progress, while starting the work on the new Indigo framework. Here is some more detail:
- Remoting: It will still be very useful in some scenarios. Missing features will be completed and bug fixing will continue.
- Web Services (ASMX): It is currently used in many applications, and it is mostly feature complete, so it makes sense to fix the remaining bugs and release it as part of Mono 1.0.
- Enteprise Services: Right now, the development of System.EnterpriseServices is not a priority, since nothing is implemented in this namespace and it will be replaced by the new service model. However, if there is interest in implementing support for it, the best approach would be to implement it on top of Indigo (that is, using the transaction management and hosting features that Indigo provides).
- System.Messaging: No plans for this. Indigo's messaging architecture is very different from that of MSMQ.
- WSE: Although its dead is already scheduled, it makes sense to continue its development since the technology that it provides will be reused in the development of Indigo, and it will be a good Indigo replacement until it is released.