.NET bound to fail...
-
No, I am not a prophet. Just listen very well, get over the so-called excitements. As days go by, the hidden MS agenda is revealing itself. I just watched the show at http://msdn.microsoft.com/theshow/ where presenter was trying hard to explain why the .NET is the principle being used by MS Passport currently. Unfortunately, MS is linking the C# to the .NET. The so-called .NET is simply building software which will be hosted on MS servers, and one will have to pay for these so-called web services. Is your company ready for this? .NET RIP :
-
No, I am not a prophet. Just listen very well, get over the so-called excitements. As days go by, the hidden MS agenda is revealing itself. I just watched the show at http://msdn.microsoft.com/theshow/ where presenter was trying hard to explain why the .NET is the principle being used by MS Passport currently. Unfortunately, MS is linking the C# to the .NET. The so-called .NET is simply building software which will be hosted on MS servers, and one will have to pay for these so-called web services. Is your company ready for this? .NET RIP :
Hi, I can see your point, but I have to disagree - because Microsoft are opening up their specifications so others can write .NET servers for any OS they want. Eventually the .NET runtime will be available on diverse operating systems such as Linux or whatever OS your into. Also, I have to admit, I'd prefer to use Windows rather than other OSes at present, esp. Win2K, which I have not managed to crash yet. Don't get me wrong though - I'm not putting down Linux - I think it's a perfectly strong and capable OS. Andrew
-
No, I am not a prophet. Just listen very well, get over the so-called excitements. As days go by, the hidden MS agenda is revealing itself. I just watched the show at http://msdn.microsoft.com/theshow/ where presenter was trying hard to explain why the .NET is the principle being used by MS Passport currently. Unfortunately, MS is linking the C# to the .NET. The so-called .NET is simply building software which will be hosted on MS servers, and one will have to pay for these so-called web services. Is your company ready for this? .NET RIP :
.NET Web Services uses SOAP, which is an Open Spec used on any platform - including Java. .Net is a lot more, it's also a brand new platform - much like the JVM. I'd say that this is the main thrust - and the main change that developers are going to have to deal with. It effectively signals the end of MFC and ATL as evolving libraries. The Web Service aspect is more marketing than anything else. Your point about who will pay for the services is interesting. It's has been pointed out that the current advertising model will no longer work for these services. Think about a search engine that publishes a Web Service, how do they get their money - what's their cost structure? I wouldn't say this is going to be a problem for .NET - more a problem for evolving the cost structure of the Internet itself. The only solution that I can think of is to pass the revenue down from the main client site down to the services that they use - this means that these services will not be free.
-
.NET Web Services uses SOAP, which is an Open Spec used on any platform - including Java. .Net is a lot more, it's also a brand new platform - much like the JVM. I'd say that this is the main thrust - and the main change that developers are going to have to deal with. It effectively signals the end of MFC and ATL as evolving libraries. The Web Service aspect is more marketing than anything else. Your point about who will pay for the services is interesting. It's has been pointed out that the current advertising model will no longer work for these services. Think about a search engine that publishes a Web Service, how do they get their money - what's their cost structure? I wouldn't say this is going to be a problem for .NET - more a problem for evolving the cost structure of the Internet itself. The only solution that I can think of is to pass the revenue down from the main client site down to the services that they use - this means that these services will not be free.
Hello there, I like your analysis. > It effectively signals the end of MFC and ATL as evolving > libraries. This is what they hope to see, but it will never happen. Of course you will see acts like Chris removing Java and ATL from the banner and substituting .NET and C#. > The Web Service aspect is more marketing than anything > else. Nice to see someone too getting it right. It is all MS marketing, as usual using programmers as halelluya singers. Peace!
-
.NET Web Services uses SOAP, which is an Open Spec used on any platform - including Java. .Net is a lot more, it's also a brand new platform - much like the JVM. I'd say that this is the main thrust - and the main change that developers are going to have to deal with. It effectively signals the end of MFC and ATL as evolving libraries. The Web Service aspect is more marketing than anything else. Your point about who will pay for the services is interesting. It's has been pointed out that the current advertising model will no longer work for these services. Think about a search engine that publishes a Web Service, how do they get their money - what's their cost structure? I wouldn't say this is going to be a problem for .NET - more a problem for evolving the cost structure of the Internet itself. The only solution that I can think of is to pass the revenue down from the main client site down to the services that they use - this means that these services will not be free.
I agree with the thread on paying for services. Yes they will not be free. However, I see nothing saying this signals the end to MFC and ATL. They can be used to build these services and many other applications. So this is no signal. A new option in VS 7 will be ATL Servers which will support the rest of the framework is one example
-
.NET Web Services uses SOAP, which is an Open Spec used on any platform - including Java. .Net is a lot more, it's also a brand new platform - much like the JVM. I'd say that this is the main thrust - and the main change that developers are going to have to deal with. It effectively signals the end of MFC and ATL as evolving libraries. The Web Service aspect is more marketing than anything else. Your point about who will pay for the services is interesting. It's has been pointed out that the current advertising model will no longer work for these services. Think about a search engine that publishes a Web Service, how do they get their money - what's their cost structure? I wouldn't say this is going to be a problem for .NET - more a problem for evolving the cost structure of the Internet itself. The only solution that I can think of is to pass the revenue down from the main client site down to the services that they use - this means that these services will not be free.
I think the point behind web services is to really allow software to interoperate, and to finally release the legions of human beings that keyboard enter accounting documents to find a higher calling. Internet sites that now attempt to cover their costs through advertising may not be a good fit for webservices, and maybe sites like google, or goto that rank paid links higher will lead in the web services arena. It's hard to tell right now. Microsoft's Biztalk initiative is pretty key in the whole webservices plan. It hopes to specify the "interfaces" that link disparate business processes, and to join together all the different mechanisms by which organizations now exchange standard information. Imagine standard interfaces that would allow you, using Quickbooks, to send an invoice electronically to your client, who uses Peachtree. Imagine a standard format that all accounting packages accepted. EDI has promised this for years and years, but only the largest companies have put it in place. No question that a whole series of web services will emerge, like Microsoft's Passport architecture, that will become fundamental pieces of application development. There will be standard services for currency exchange, payroll deduction calculations, translation, calculating shipping costs (no question FedEx and others have this in the works), etc. and it will be adventageous for we as applications developers to make use of these services. Will we all run out tomorrow and buy subscriptions to a whole list of webservices... I doubt it. But I do believe that vendors will certainly open up their systems to make it easier to integrate with their systems. That's a more reasonable economic driver IMO. I don't think