| ActiveMac | Anonymous | Create a User | Reviews | News | Forums | Advertise |
|
|
|
User Controls |
|
New User |
|
Login |
|
Edit/View My Profile |
|
|
|
|
|
|
|
ActiveMac |
|
Articles |
|
Forums |
|
Links |
|
News |
|
News Search |
|
Reviews |
|
|
|
|
|
|
|
News Centers |
|
Windows/Microsoft |
|
DVD |
|
ActiveHardware |
|
Xbox |
|
MaINTosh |
|
News Search |
|
|
|
|
|
|
|
ANet Chats |
|
The Lobby |
|
Special Events Room |
|
Developer's Lounge |
|
XBox Chat |
|
|
|
|
|
|
|
FAQ's |
|
Windows 98/98 SE |
|
Windows 2000 |
|
Windows Me |
|
Windows "Whistler" XP |
|
Windows CE |
|
Internet Explorer 6 |
|
Internet Explorer 5 |
|
Xbox |
|
DirectX |
|
DVD's |
|
|
|
|
|
|
|
TopTechTips |
|
Registry Tips |
|
Windows 95/98 |
|
Windows 2000 |
|
Internet Explorer 4 |
|
Internet Explorer 5 |
|
Windows NT Tips |
|
Program Tips |
|
Easter Eggs |
|
Hardware |
|
DVD |
|
|
|
|
|
|
|
Latest Reviews |
|
Applications |
|
Microsoft Windows XP Professional |
|
Norton SystemWorks 2002 |
|
|
|
Hardware |
|
Intel Personal Audio Player 3000 |
|
Microsoft Wireless IntelliMouse Explorer |
|
|
|
|
|
|
|
Site News/Info |
|
About This Site |
|
Affiliates |
|
ANet Forums |
|
Contact Us |
|
Default Home Page |
|
Link To Us |
|
Links |
|
Member Pages |
|
Site Search |
|
Awards |
|
|
|
|
|
|
|
Credits |
 |
Is Microsoft ready for Web services? | |
|
||
| Time: 16:27 EST/21:27 GMT | News Source: ZDNet | Posted By: Robert Stein | ||
|
COMMENTARY--Microsoft has traditionally dominated the small-business software market, where the company’s platform remains a popular choice. However, as Web services emerge as a viable and industry-shifting technology, questions have emerged as to whether Microsoft has what it takes to gain real inroads with larger-sized companies. It has become increasingly evident that Microsoft is caught between a standard and an operating system, and that its continuing proprietary approach may not be viable in the Web services era. | ||
|
Write Comment
Return to News |
Displaying 1 through 25 of 328 Last | Next |
The time now is
12:55:49 PM
ET.
Any comment problems? E-mail us |
| #1 By 135 (208.50.206.187) at 2/6/2003 5:54:28 PM |
|
"and that its continuing proprietary approach may not be viable in the Web services era. "
Woot! Maybe that's why SOAP is a standard? |
| #2 By 3339 (65.198.47.10) at 2/6/2003 6:11:02 PM |
| So what, soda, you think SOAP is that universal business adaptor (with European module included, right?) in the IBM commercial? That's funny. It's going to take a bit more than SOAP to eliminate the platform dependency issue--despite what Ballmer told you three years ago. |
| #3 By 2332 (65.221.182.3) at 2/6/2003 8:19:21 PM |
|
Can somebody point out what's proprietary about Microsoft's approach to web services?
It's based on SOAP and XML, both standards. It's governed by the rules outline by the WS-I, a standards body. |
| #4 By 135 (208.50.206.187) at 2/6/2003 8:27:49 PM |
|
sodajerk - There is no Universal Business Adapter.
I don't think a graphics artist is really in a position to be telling us about application integration issues. |
| #5 By 61 (65.32.170.1) at 2/7/2003 12:50:13 AM |
|
red: that's ZD for ya....
BTW, we have enough freaken Soda's around here, why don't you try picking an original name? |
| #6 By 135 (209.180.28.6) at 2/7/2003 10:48:01 AM |
| I am going to become CPUSoda |
| #7 By 3339 (65.198.47.10) at 2/7/2003 12:55:57 PM |
|
I haven't been doing graphic design for over two years, soda. I'm a web and database developer. For a small firm? Yes, 350 people, but I still know what I'm talking about.
RMD, the problem is the standards may be able to pass data between platforms, but there are still and will always be other platforms present in large enterprises: mainframes, Nix servers, etc... You will still need to program web services for these systems, but you will not be able to use .Net. If all of your systems are non-MS, or significant portions of them, or even a small portion of them, you will need programmers and development in something other than .Net. If you are supporting multiple technologies and want to focus on one, which would you pick--the one that works for all platforms or the one that forces you to either change your entire infrastructure and/or support the other technology (which would happen to work on all platforms) too? |
| #8 By 135 (209.180.28.6) at 2/7/2003 1:19:05 PM |
|
sodajerk - "Yes, 350 people, but I still know what I'm talking about. "
Thus far I've seen no evidence of that. " If all of your systems are non-MS, or significant portions of them, or even a small portion of them, you will need programmers and development in something other than .Net. " Generally if you have systems in-house you will either have developers who can work on them, or a support contract with the vendor. "If you are supporting multiple technologies and want to focus on one, which would you pick--the one that works for all platforms or the one that forces you to either change your entire infrastructure and/or support the other technology (which would happen to work on all platforms) too? " Well obviously the one that works for all platforms, which is why we are going down this web services path with SOAP and such. The force you to change your entire infrastructure is the Java mindset... that mindset is bad. |
| #9 By 1845 (12.209.152.69) at 2/7/2003 1:19:40 PM |
|
jerk, i'm lost here.
"If you are supporting multiple technologies and want to focus on one, which would you pick--the one that works for all platforms or the one that forces you to either change your entire infrastructure and/or support the other technology (which would happen to work on all platforms) too? " I'm not trying to argue (you can see by my post count that I haven't been in the mood for that lately), I just don't understand. If you use XML web services written in .NET, they can be consumed by SOAP consumers written in Perl, Python, C++, etc on any platform. In like manner, .NET apps can consume web services written in C++, Objective C, or whatever. So, it doesn't seem to me that using .NET for consumption/production of web services in any way locks you into anything. |
| #10 By 3339 (65.198.47.10) at 2/7/2003 1:36:11 PM |
|
Bob, my point is: most web services will be developed on other platforms (Unix servers, Mainframes, etc...). Yes, you can pass the data, but if you have to support developers building services in Java for these platforms (or Python, or Perl, or whatever), what is the point in having (let's say it's an even split for a hypothetical business) 50% Java and 50% .Net. Yes, you'll be able to pass between the two, but you have to support two entirely different development efforts. Why would you do this if Java will work for both?
Also, just because the goal of web services is to pass data, that doesn't mean you will not ever want to create a tighter programmatic bridge between two separate systems. People are developing these bridges, but again if one will work for both systems, why not use it. soda, "Generally if you have systems in-house you will either have developers who can work on them, or a support contract with the vendor." This says nothing to explain why you would want to have two completely disparate methods of development. Yes, developers should know what they are developing... That's not a very interesting point. My point is developers will need to know two technologies or you need two sets of developers if you go the .Net route and have non-Windows systems. This isn't necessary if you use Java. "Well obviously the one that works for all platforms, which is why we are going down this web services path with SOAP and such." Thank you. Yes, you'd use Java. Just saying SOAP over and over again doesn't explain how you will develop on the non-Windows systems. "The force you to change your entire infrastructure is the Java mindset... that mindset is bad." Have no clue what the hell that means. "The force you to change" huh? How is the Java mindset the one that requires infrastructure change? That's ridiculous--where Java has established itself is in nearly ALL systems that aren't Windows--and even then they have a strong presence in the Win world on the server. Microsoft is the one that wants you to change your whole infrastructure. Are you telling me GM doesn't have any mainframes or Unix systems? You are saying that .Net will be used--how without getting rid of those mainframe and Unix systems? .Net is completely useless for Unix and other systems development so if you want to use .Net you have to replace those systems. This post was edited by sodajerk on Friday, February 07, 2003 at 13:38. |
| #11 By 1845 (12.209.152.69) at 2/7/2003 3:11:21 PM |
|
jerk, ah, gotcha.
"what is the point in having (let's say it's an even split for a hypothetical business) 50% Java and 50% .Net. Yes, you'll be able to pass between the two, but you have to support two entirely different development efforts. Why would you do this if Java will work for both?" Hard question. Obviously having a new technology for the sake of having it is not the answer here. I think the real answer is that there are a good deal of companies that already have invested in COM/COM+ applications. With .NET, that existing logic can be exposed as web services for the sake of non Microsoft based portions of your organization and for the sake of a company's partners. If you don't have any existing Windows based code, I can't see why you would swith to it for the sake of web services(unless, you were doing a mass migration away from some other architecture). Some anecdotal experience - in the past I've done some contract programming for Sysco. Inside their server room I saw several Windows 2000 servers running ISA, SQL, Exchange, etc. I also saw the IBM AS/400. They have a substantial investment in COM/COM+ technologies, but they also have non Windows code running on non Windows platforms. For them, web services would allow the COM/COM+ investment to be leveraged in new ways. That seems like a value add to me. If they had done everything already in Java, things might be different, but the fact is, they didn't so they have investment in disperate hardware and software platforms. Java doesn't bridge the gap between disperate coding platforms (e.g. software frameworks like Java2 or .NET), but web services do. |
| #12 By 3339 (65.198.47.10) at 2/7/2003 4:05:03 PM |
|
Bob, no offense, but in no way did you get me. You described a situation where you still have non Windows code on non Windows platforms. I didn't say that .Net couldn't leverage COM. Or that it had no advantage. I said it was a disadvantage to support two development efforts.
"Java doesn't bridge the gap between disperate coding platforms (e.g. software frameworks like Java2 or .NET), but web services do." No sh!t. And you can use Java with web services. The point being--you can code in Java on disparate systems though. In a mixed environment, choosing .Net means you develop code to pass the data to web services in >net on the windows boxes, and for the non-Windows boxes what do you do? You use another technology. |
| #13 By 1845 (12.209.152.69) at 2/7/2003 4:54:24 PM |
|
jerk, I understand that two dev technologies isn't ideal. I also understand that quite often a large company will have two or more dev technologies. If you have already two or more dev technologies, then using .NET to wrap existing COM/COM+ objects in web services could be a boon to you. This post was edited by BobSmith on Friday, February 07, 2003 at 16:54. |
| #14 By 3339 (65.198.47.10) at 2/7/2003 6:03:16 PM |
|
And what if they use CORBA? Or Java? And besides (and I'm a bit weak on this so excuse any ignorance hear) what would the value of .net-wrapped objects be on the non-windows side of things? Can you deploy .net-wrapped COM objects on an IBM system? I can only see a value to the window portion of your systems, but wouldn't that mean you reaped some gain for just a portion of your system? And basically broken the purpose of COM? So that doubles up work more. (As I said, I'm, iffy on this, but really, what the benefit of wrapping COM objects in a windows-only wrapper?)
It's one thing to say that companies can handle more than one development technology--it's another thing to say that it's desirable to add an additional one when the very purpose of web services is integrating disparate platforms. Besides the question was: what is proprietary about .Net? Don't know why it's a mystery to some, it's very easy: it's a windows-only technology that cannot be deployed on non-Windows systems. This was in essence my only point, and it's very clear that it can easily be a detriment to many enterprise environments. This post was edited by sodajerk on Friday, February 07, 2003 at 18:13. |
| #15 By 135 (209.180.28.6) at 2/7/2003 6:07:58 PM |
|
sodajerk - "This was in essence my only point, and it's very clear that it can easily be a detriment to many enterprise environments. "
Ahh, a preconceived notion with no substantial basis in reality. The easiest argument to rip to shreds. |
| #16 By 3339 (65.198.47.10) at 2/7/2003 6:12:53 PM |
| "The easiest argument to rip to shreds. " which is why you you've done nothing to do so but insult me? Uh, huh. |
| #17 By 3339 (65.198.47.10) at 2/7/2003 6:16:37 PM |
|
what's preconceived about it? It seems pretty logical to me that if I can't do anything with .Net on a non-Windows machine, and I have non-Windows machines--I wouldn't want to use it. That's a fully conceived thought.
Where's the lack of basis in reality? It is true that .Net doesn't run on other platforms. This market research shows that it's nearly 50/50-with half not wanting to use .Net. "The easiest argument to rip to shreds." Please do... |
| #18 By 1845 (12.209.152.69) at 2/7/2003 6:22:25 PM |
|
"what would the value of .net-wrapped objects be on the non-windows side of things? Can you deploy .net-wrapped COM objects on an IBM system?"
The point is, if you are using COM right now, nothing but COM can communicate with it. If you wrap COM in .NET, then via web services everything that is web services aware can now communicate with it. "Besides the question was: what is proprietary about .Net?" The question was : Can somebody point out what's proprietary about Microsoft's approach to web services? Yes, the .NET runtime currently requires Windows. If you want to say that that requirement makes it proprietary, fine, go ahead. .NET's consumption/production/transport of web services, though is standard and non proprietary. Also, with non Microsoft implementations of the CLI, I'd wager in the next 18 months or so, we'll see .NET code be as portable as Java code. At any rate, I'll freely admit that the current and only full implementation of the CLI is Windows only. "it's a windows-only technology that cannot be deployed on non-Windows systems." The difference is that, previous Microsoft technologies (like COM) were end to end Windows technologies. Not only could you only deploy on Windows, but you also could only consume from Windows. With web services, half of the equation doesn't have to be Windows. This is a potential benefit to enterprises that have both Windows and other technologies. |
| #19 By 3339 (65.198.47.10) at 2/7/2003 6:38:24 PM |
|
"The difference is that, previous Microsoft technologies (like COM) were end to end Windows technologies." I love this one. SO what? The question isn't is it better than what MS had before; the question is is .Net the solution and impetus for the web services wave.
"Not only could you only deploy on Windows, but you also could only consume from Windows. With web services, half of the equation doesn't have to be Windows. This is a potential benefit to enterprises that have both Windows and other technologies." And my point is it still has disadvantages to wholly cross platform technologies like Java. And I don't know why you think we are referencing RMD's words here (since my initial point was that to get the data into a standard format isn't the be all end all and is not at all the bottleneck to choosing .Net); I'm referring to the thesis of the story... the reason .Net isn't being adopted by many is because it is proprietary--it cannot be deployed on a non-Windows system. This post was edited by sodajerk on Friday, February 07, 2003 at 18:42. |
| #20 By 3339 (65.198.47.10) at 2/7/2003 6:43:40 PM |
| Haven't there been Java COM wrappers for quite a few years now anyway? |
| #21 By 3339 (65.198.47.10) at 2/7/2003 6:48:40 PM |
|
kevin, you make me laugh. I don't care about your paragraph about separating the GUI from the logic, it's completely irrelevent. For all intents and purposes, .Net is a windows-only solution for the time being. You can disagree--most people know better.
Regarding wrapping COM, as I post above--people have been wrapping COM in Java for over 5 years now as far as I am aware. But that doesn't matter. Because there is a benefit from .Net, doesn't negate the obstacle that it can be deployed on AIX, HP/UX, Solaris, mainframes, etc... This is the barrier that I've been trying to point out and for some reason everyone's baffled. I don't get it... |
| #22 By 3339 (65.198.47.10) at 2/7/2003 7:05:33 PM |
|
For now, yes, Mono more or less means nothing.
As for what you are doing or what MS's motivations are--I don't care--none of that negates the market reality. It is a barrier to many enterprises. Have I said anything otherwise? |
| #23 By 135 (208.50.206.187) at 2/7/2003 11:11:55 PM |
|
sodajerk - "And my point is it still has disadvantages to wholly cross platform technologies like Java. "
Ahh, see there's one of your problems. Java isn't cross-platform... it is rather it's own platform. SOAP is truly cross-platform, as it allows any platform to talk to any other platform. See, so now instead of having to rewrite all the COBOL code on the Mainframe with Java, or all the VB code on the NT server into Java, and all the Perl code on the Unix box in Java... We just hook them all up together and leave them mostly untouched and working just fine. And now you learn why your argument is a detriment to most enterprise environments. |
| #24 By 3339 (64.175.42.78) at 2/8/2003 4:03:04 PM |
|
The Java developers I know don't REWRITE legacy or platform-specific code OVER AGAIN with Java. Most of that code has been bridged or redeveloped already. The little non-Java code they interact with they already have the connections to Perl and so forth. I see softies acting as if nothing interacts with COM, but there were tons of Java/COM bridges back in '97 (maybe even a few earlier than that).
"We just hook them all up together and leave them mostly untouched and working just fine." That's a strategy, and that's fine. Are you saying these systems weren't hooked up without SOAP and .Net before a year ago? I guess other people's strategies has progressed different from yours. Rather than leaving them untouched--the developers I know continue development where it is beneficial. |
| #25 By 135 (209.180.28.6) at 2/8/2003 4:50:41 PM |
|
Ok, I am convinced. Sodajerk just likes to argue for the sake of arguing.
He's yet to make a consistent coherent argument for anything. Right here in this thread he changed direction of attack at least half a dozen times. |
|
Write Comment
Return to News |
Displaying 1 through 25 of 328 Last | Next |
The time now is
12:55:49 PM
ET.
Any comment problems? E-mail us |
