>This has to do with my postulate that web services will want to be able to transport behavior across the tier boundary, and the contract in XML regarding data types is not at present capable of transmitting the 'natural' common p-code of IL for client-side execution in the client's CLR is not now strong enough to do this. It's wild-eyed speculation that web services may ultimately construct and deliver custom client-side objects by carrying back packages of IL in XML streams for the client to mung. There are lots of ways of doing it, and the hypothesis may be inherently flawed by the definition of what is deliverable by a web service as it exists today; I haven't done as much reading on the topic as I should before spouting theory. I'm not convinced that web services will be ultimately successful without the ability to deliver client-side behaviors, and further speculation that we are entering a world where the CLR is touted as a universal virtual machine seems as flawed as the
>current implementation of the Java VM.

I'm not sure exactly what you're looking for - binary object representations that include method signatures and the code that goes along with it?

That would be folly and should definitely not happen as that would make WS totally non-cross platform... Web Services are a data transport and as such should transmit data structures, which is pretty much what the spec does.

Web Services will not completely replace binary protocols like DCOM and CORBA simply because those protocols will be faster for direct machine to machine communication in a controlled environment. System services still require this type of thing with performance that Web Services won't be able to touch and flexibility that is lower than what a Web server based interface can provide.

With some logic on the CLR's part it would be possible to automatically be able to map object to object assuming the same object exists client and server side, but for some dim witted reason Microsoft thinks this is not even worth considering as a built-in feature. I discussed this kind of thing with various Microsoft people and they either didn't get it, or it's not really possible to do.

I think it's important to have a way to automate object mapping using the data structures travellign over the wire as the transport, but that's purely an optional feature that makes life easier. Given that a language doesn't have hte capability and tools to do this (and the CLR doesn't without a fair amount of code anyway), then you'd have to write manual data mapping code to reattach the data to the business logic on the client side.

Microsoft does what MS does, right? It's all or nothing always - I think that their take for Web Services and remote connection for everything is not realistic for a number of situations. But that doesn't mean that the technology is flawed - it just means that it's overhyped to fit into places where it'll be better to use more traditional models of data access/management.

>OIC; I had thought that he alluded to the server engine being a set of CLR components. I think that a .Net language is going to suffer from the syntactic flaws that a '.Net' VFP would suffer from, in that the internal language modelling the world to be manipulated isn't reflected well by the syntax underlying the CLR; there's a need to build a rich set of concepts that will be relatively expensive to implement in IL. I don't see a benefit to moving these products to the managed code arena, unless you and John postulate that SQL Server and Office will run on all CLR client platforms rather than just Windows platforms; there's something to be said for unmanaged code for efficiency and tight integration with the platform. Lots of things are going to remain as unmanaged code, and these two products sit at or near the top of my list of things that might stay so.

Well, I can see Office using CLR language constructs which is probably a close match to the way that things work already. But for Office that would also mean that these objects would have to be either native CLR code or else mapped to native CLR objects that access the underlying COM code. Which seems silly either way...

Good point about the language issues. I hate Transact SQL though and getting a real language would be very nice inddeed. But how would you run a SQL Statement in that environment? Calling an object that does an execute? T-SQL like VFP has the advantage of not requiring strings but can put SQL directly into the code, which is much easier to code and get right than hairy strings that are concatenated together.

It's like you said - things will be interesting for the near future as people figure out all the ugly things that we didn't hear about during the beta. I think deployment, security, performance and the whole garbage collection/no concrete destructors will give a lot of people serious headaches when it comes to building commercial grade applications.