Well in .NET we've done a lot of work in the space I mean as you know Windows development via COM in which you had to copy the component up there and then utilize an API call to actually register that with the windows registry. So we wanted to eliminate those pieces. So a lot of .NET it's very very simple for you to go in and just copy the files up there and it just works. It's a very very simple deployment model. Now for enterprise services particularly, you have to give a lot of thought about what are the one time semantics of that component. So an EJB utilizes the deployment descripter to say what transactions there are, what type of roles, what security you have etc.. Now in .NET we also support the construct of having a configuration file that enables me to have a run time discovery of attributes and things of that nature but what's interesting about .NET is we support a thing called declarative programming or attributal programming where you can go into your source code and annotate that directly and provide such information to the run time layer such as web services, I'd like to add this method as a web service, or I'd like to have this component as being transactional, and that becomes part of the contract of that component embedded inside the source code. Let me talk a little bit about why we do that. We believe that there are certain types of attributes and certain types of run time behaviour that are absolutely critical to the run time, the assurance of correct behaviour at run time. So how can a developer encode the proper run time semantics in the source code in order to enable this component to run correctly? So I'll give you an example of say transactions. Should transactions be modified by the administrator in the field? Once a programmer codes some component and they go out and they actually build this component to be transactional and it's deployed can you imagine the trouble that may be caused if an administrator goes in and makes that non transactional, and you can do that with deployment descriptors where as with the .NET framework I make a component transactional inside of the source code when it's compiled down that's part of the contract and a developer rather an administrator can never change that. So those are the sort of deployment semantics. We have this distinction between things that should be configurable by administrators and things that shouldn't, things that need to be a part of the core contract of that component.