Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

.NET, the why, not the what.

By ajm in Op-Ed
Sat Jun 22, 2002 at 02:09:45 PM EST
Tags: Software (all tags)

There have been many articles about what .NET is. This isn't one of those. Instead I'd like to suggest one possible explanation for why .NET was created, and what Microsoft hopes to get out of it. I'm sure this isn't the whole story, most things are done from a mixture of motives, but I think it gives a useful insight into what's going on.

In his latest strategy letter Joel Spolsky describes a general principle, Smart companies try to commoditize their product's complements. It's interesting to try and apply this to Microsoft's .NET efforts. In programming the best way to learn a language is to try to write programs in it. With these sorts of ideas the best way to understand them is to try and apply them.

There are quite a lot of buzzwords and three letter acronyms (TLAs) in this article. I try to supply a definition or explanatory link when I mention each one for the first time. It may sound like it's just marketing speak but I think that to understand .NET you need to understand who it's targeted at, and it's not the programmers. This, rather than the technology language of JVMs, CLRs and CLIs, is the language spoken by the people who choose between J2EE and .NET, if you don't understand the language you'll be left out of the conversation.

Let's look at what's called the Enterprise Computing space. This is the area of large systems supporting company operations, systems produced by companies like, SAP for Enterprise Resource Planning (ERP), Siebel and PeopleSoft for Customer Relationship Management (CRM), i2 and JD Edwards for Supply Chain Management. Installing and customizing these things is the bread and butter of the large consulting firms, and there is a lot of money involved. In 1999 a MetaGroup survey found it took a company an average of 23 months to get an ERP system implemented at a cost of $12.7 million over the period.

Imagine that Microsoft wants to move into this space. This is a reasonable thing for them, they've saturated the desktop OS market at home and in corporations, if they want further expansion enterprise computing certainly has the money. Thinking about this in terms of smart companies try to commoditize their product's complements, what sort of complementary products would be useful for an OS used in enterprise computing?

One of the most important ones is good integration capabilities. This also has a buzzword, Enterprise Application Integration (EAI). A large company won't have just, for instance, SAP. They will also have systems they wrote themselves, other packages they've implemented in the past, systems from companies they've acquired, and a general mish-mash of stuff. To make all of this work together you need to be able to interconnect the systems. For instance orders entered into the SAP ERP system may generate general ledger entries that have to be passed to a home grown CICS system running on an s390 mainframe.

Products to make integration easier are provided by companies like TIBCO and webMethods. It has been a lucrative area for them. webMethods' stock went up 507.5 percent on its first day. OK, that was in 2000, but very impressive even for then.

So, what does Web Services and .NET do to the enterprise integration business? It commoditizes it. Microsoft's vision is that if all the applications offer Web Service access then they are easy to plug together, and the obvious vendor to supply the plumbing is Microsoft. With enterprise integration reduced to a commodity Microsoft's chances of getting into the Enterprise space improve, with no TIBCO or webMethods to buy there's now more money available for Microsoft. If they can position themselves as the integration leader, with good support built into the OS they control and the tools they provide then it's much more likely they'll be chosen instead of IBM, SUN or HP to provide the OS, and possibly also the consulting work that goes along with the implementation.

Even better, if Microsoft can convince SAP, Siebel and other Enterprise Software vendors to offer .NET/SOAP access in their applications then they will succeed where TIBCO and webMethods have not, they'll get the application vendors to pay for the integration plumbing. And it looks like this is happening. Microsoft, and others, are generating such hype and buzz around Web Services that customers are starting to demand .NET/SOAP access even when they have no compelling use for it yet. It's turning up in RFPs already, and this means that SAP, Siebel and PeopleSoft are already, or will soon be, adding it to their systems.

Obviously there are real problems with making all of this stuff work in the real world. There is more to integration than just plugging the pieces together syntactically, you need to understand the semantics and provide appropriate transformational code where it's required. However, when it comes down to choosing your next enterprise platform the decision is made not just based on current real capabilities but on how compelling the future vision is. If Microsoft can convince Chief Information Officers (CIOs) of their vision they'll do very well indeed in the Enterprise Computing space, and that's what .NET is all about. It's a vision of seamless enterprise application integration, running over Microsoft plumbing that comes either bundled with the OS or is available as a closely integrated extension. The next couple of years will tell how compelling this vision is, and whether Microsoft's current growth will continue.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o strategy letter
o Joel Spolsky
o Enterprise Resource Planning
o Siebel
o PeopleSoft
o Customer Relationship Management
o i2
o JD Edwards
o Supply Chain Management
o MetaGroup
o Enterprise Application Integration
o general ledger
o s390
o webMethods
o 507.5 percent
o Also by ajm

Display: Sort:
.NET, the why, not the what. | 71 comments (50 topical, 21 editorial, 0 hidden)
My take on .NET (4.42 / 7) (#3)
by DeadBaby on Fri Jun 21, 2002 at 11:15:03 PM EST

I really think .NET is the start of the post-OS dominace phase of Microsoft. They must have realized that they had the desktop market pretty much owned. In many ways, I think Linux proved this to them. Here was an OS that had driver support, performence, security, stability and hordes of programmers working on it and... It failed terribly on the desktop -- for now.

I think Microsoft realizes that they are in the perfect posistion to change the direction of personal computing. Is Linux a threat? Sure but the actual lower level plumbing of an OS is becoming less and less important. I think Microsoft might be very happy letting Dell ship Linux with Mono on their computers because their platform would still be promoted. Developers would still flock to Microsoft. Imagine if .NET has perfect runtimes on the Mac, Linux, etc. Microsoft stays dominate AND takes care of their OS monoply problem while still controlling the industry.
"Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity -- in all this vastness -- there is no hint that help will come from elsewhere to save us from ourselves. It is up to us." - Carl Sagan

Am I the only one... (3.75 / 4) (#5)
by Kasreyn on Fri Jun 21, 2002 at 11:44:35 PM EST

...whose head is spinning from all the manager-babble? Sheesh, I think I'd need an MBA to successfully read this article. That, or a LOT more patience than I have for the whole sordid topic of business. For me, the amount of time that would be required to get my head around this article is so utterly not worth it that my response is "screw it!"

I've always thought manager-babble is a secret code language designed to keep others from understanding the dastardly things corporate types conspire to do. =P

If not for the fact that this looks quite well-researched, I'd be tempted to -1 it for being hopelessly incomprehensible. But then I remembered that there's always the chance that I'm just hopelessly stupid, and it's perfectly intelligible to everyone else. So I shall abstain.


"Extenuating circumstance to be mentioned on Judgement Day:
We never asked to be born in the first place."

R.I.P. Kurt. You will be missed.
manager-babble? (none / 0) (#20)
by ajm on Sat Jun 22, 2002 at 09:06:01 AM EST

At the beginning I try to say that though it sounds like manager-babble it's important to try and understand this stuff if you want to understand .NET. These words, though inventions and over used, have the same sort of power with the people that use them as Model View Controller or Singleton have with programmers. They are shorthand for larger concepts and packages. To take part in the conversation you need to be able to speak the language.

[ Parent ]
Singleton? MVC? What's that? (none / 0) (#41)
by swr on Sat Jun 22, 2002 at 04:19:28 PM EST

These words, though inventions and over used, have the same sort of power with the people that use them as Model View Controller or Singleton have with programmers.

I've met quite a few programmers in Real Life. Most of them were not familiar with those two terms.

The first programmer to mention .NET to me was an ASP programmer. He said .NET was cool because you could separate your ASP code out from your HTML.


[ Parent ]
MVC (none / 0) (#48)
by ajm on Sat Jun 22, 2002 at 07:40:28 PM EST

In real life I play a programmer and all of the people I work with are at least aware of software patterns, and most are more than aware. They are not the be all and end all of software but do provide useful "code words" for commonly occuring situations. In the same way, ERP means something to people. It may be a "buzzword" but it's sometimes useful, like software patterns are, for providing a shorthand in conversations and a richer vocabulary for discussions.

[ Parent ]
You're not the only one... (none / 0) (#24)
by Stick on Sat Jun 22, 2002 at 10:55:44 AM EST

I just can't understand it. I don't even understand what .NET really is either. Of course, Microsoft stuff never made sense to me. I'm only just figuring out stuff like OLE, ActiveX, MFC, COM etc.

Stick, thine posts bring light to mine eyes, tingles to my loins. Yea, each moment I sit, my monitor before me, waiting, yearning, needing your prose to make the moment complete. - Joh3n
[ Parent ]
I thought *everyone* knew that... (none / 0) (#43)
by MisterX on Sat Jun 22, 2002 at 05:00:26 PM EST

I don't even understand what .NET really is either ... I'm only just figuring out stuff like OLE, ActiveX, MFC, COM etc.

...that apart from MFC, they're all just DDE?

[ Parent ]

.NET -- the overused brand name (long) (none / 0) (#44)
by UncleMikey on Sat Jun 22, 2002 at 05:13:20 PM EST

OK. I've recently been forced for various reasons to learn a lot more about .NET than I ever really wanted to. I am, in fact, now programming for a .NET-based prototype. I'm not happy with the idea -- not because I hate Microsoft (I do) nor because I think .NET sucks (I don't -- I have no firm opinion on that score, yet), but because the decision was made for marketing reasons (which I agree with, but don't like), not technical ones.

ANYWAY, what is .NET? It's an umbrella which includes several otherwise orthogonal pieces. It's been deliberately lumped together because the pieces as Microsoft provides them have been designed to play nice together, and Microsoft wants to confuse the issue so that you use only their stuff to do it, but you don't actually have to.

Those pieces include:

  • A Common Language Runtime engine, the idea of which is very similar (deliberately) to the Java Virtual Machine. The difference is that at least three languages (Managed C/C++, C#, and Visual Basic) compile to the CLR, whereas most JVMs only do Java. I think I've heard that ActiveState has a Perl.NET  now, as well, but I'm not clear on whether this also uses the CLR or whether they just include a framework to interoperate with the Web Services.
  • A framework of classes that provide a common set of services across all of the supported languages. In short: if your lanaguage can compile to the CLR, you can use these classes.
  • Those classes, in turn, implement an RPC mechanism based on SOAP/XML, and WSDL -- both entirely open standards, altho' Microsoft may have done some deliberate and possibly incompatible extension -- I haven't gotten far enough yet to know. SOAP is an RPC mechanism that uses XML to encode data, and WSDL is a way of asking a web-deployed object what its interface is like, said description also provided via XML. This mechanism can be used to implement both XML Web Services, and what they call .NET Remoting. The former is essentially a variant on the CGI model; the latter is another spin on CORBA/DCOM distributed objects.
Each of these things is actually an entirely separate piece. You can write more traditional Windows and console applications in C#; you can use the .NET framework in langauges other than C#; and you can theoretically use lanaguages that have nothing to do with .NET to interoperate with .NET-provided XML Web Services (because WDSL tells you how to call them). Microsoft even proves this point by providing an extension to the ATL library for writing and consuming web services in unmanaged (traditional) C++.

How well any of this actually works...I'll have to report another day. We've only just made the decision to start swimming in these waters, and I don't actually know where the sharks are, yet...
[ Uncle Mikey | Radio Free Tomorrow ]
[ Parent ]

Misguided Answer... (none / 0) (#45)
by Carnage4Life on Sat Jun 22, 2002 at 05:43:04 PM EST

The .NET you describe is simply the .NET Framework which is no less confusing or malicious than Java( is it a language, a runtime, a platform, a set of base classes or ...?)

I have answered the "What is .NET?" question a whole bunch of times both on K5 and Slashdot. Here's a link to my last such post

[ Parent ]
Lots of confusion (none / 0) (#58)
by ucblockhead on Sun Jun 23, 2002 at 11:03:38 AM EST

This isn't quite right, though that's not surprising considering how confusion Microsoft's own documentation is on the subject. For one thing, "Managed" has nothing to do with the "CLR", in that you can quite happily compile many "unmanaged" C++ apps to Microsoft's version of bytecode. "Managed" is a completely separate concept, though it depends somewhat on the CLR. (And confusingly, I've seen them refer to the .NET framework as being part of the CLR.) You can use the CLR without being managed, but you can't be managed without using the CLR.

What makes this all confusing is that while making other languages use the .NET framework is very interesting, having other languages use the CLR is not that interesting at all, because it is the framework that contains all UI and OS services.

Also, Microsoft is really only providing two real managed languages. "Managed C++" is only an upgrade path. Microsoft explicitly calls it this, and if you've worked with it, you know why this is. "Managed C++" is not a language a sane programmer would develop in. The only reason to use it is to try to leverage bits of unmanaged C++ code.

In regards to SOAP, from what I've seen, Microsoft hasn't done anything explictly to be "nonstandard", however, in my experience, SOAP's much vaunted interoperability is a complete and utter crock of shit. Try and hook up a java SOAP client to an MS SOAP server or vice versa! You can't blame the problems on either...more it seems that neither side has implemented the "full" standard, and that they picked different subsets. My own feeling is that the reason for this is that SOAP is itself just too fucking complicated. I've been on two projects that used SOAP now, and frankly, we could have developed faster had we just used something ad hoc and home grown. As an RPC mechanism, it sucks shit. As a public remoting model, I can see where it might be useful.
This is k5. We're all tools - duxup
[ Parent ]

The problem of interop (none / 0) (#71)
by UncleMikey on Tue Jun 25, 2002 at 02:26:58 PM EST

SOAP seems to run into the same problem a lot of standards do in their early days. CORBA had the same problem; so have most ISO standards (X.400, anyone? Or even H.323 until relatively recently).

Specifying a format for data and a set of commands is not enough. If a standard does not explicitly say: "You must implement all of these things exactly or you can't claim compliance", you're guaranteed to get non-interoperable crud.

Of course, you're also correct that the 'S' in 'SOAP' has long-since ceased to mean 'Simple'.
[ Uncle Mikey | Radio Free Tomorrow ]
[ Parent ]

WTF (5.00 / 1) (#30)
by mirleid on Sat Jun 22, 2002 at 12:36:26 PM EST

...what manager babble are you talking about? Most of the stuff that I read in there is hard tech, but I would love to be proved wrong...

Chickens don't give milk
[ Parent ]
depends on point of view (none / 0) (#49)
by ajm on Sat Jun 22, 2002 at 07:43:57 PM EST

From the outside, if you only see the marketing, ERP may look like babble. But I think you're right, from the inside ERP, CRM, Supply Chain Management etc. are useful concepts for programmers to understand. Just like AbstractFactory, Chain of Responsibility, or other software patterns to some extend ERP is a business pattern materialized in software. The marketecture vs architecture debate will always be with us though.

[ Parent ]
The entire premise of your article is flawed (4.40 / 5) (#6)
by Carnage4Life on Sat Jun 22, 2002 at 12:03:55 AM EST

The bottom line of your article is:
So, what does Web Services and .NET do to the enterprise integration business? It commoditizes it. Microsoft's vision is that if all the applications offer Web Service access then they are easy to plug together, and the obvious vendor to supply the plumbing is Microsoft.

When it boils down to it XML Web services are just SOAP which is XML over HTTP (although some seem to imply more protocol diversity is possible and necessary) and are not tied to any platform, plumbing or architecture. The biggest way a "commoditize our complement" ploy can fail is if the vendor reduces the barrier to entry in the market they are interested in as well. If your premise is actually correct then Microsoft has done exactly this with a dubious promise of payoff at best.

Disclaimer: This post is my opinion and does not reflect the thoughts, opinions, intentions or strategies of my employer.

I don't think it's flawed because ... (none / 0) (#19)
by ajm on Sat Jun 22, 2002 at 09:02:32 AM EST

Sure the barrier to entry may go down but I think Microsoft will be able to exploit the new opportunities better than the other players. They could well end up defining what the market is if their implementation gets enough mind share. Sure other players will get some business, but Microsoft will get lots and may be able to use their software churn techniques in the future to push these people out later.

[ Parent ]
Vastly improved, and very thought provoking... (5.00 / 3) (#7)
by Jodiah on Sat Jun 22, 2002 at 12:06:28 AM EST

If this turns out to be the direction MS is going than it would appear to be a very shrewd way of leveraging market dominance in one area in order to gain market dominance in another...

Does MS DO that? ;)

PS, much better with more details, still not an easy read, but its worth the work.

+1FP (3.33 / 3) (#11)
by buck on Sat Jun 22, 2002 at 03:08:25 AM EST

Nice article, comments from the MS apologists in the crowd notwithstanding.
Quite an eye-opener and one I can actually relate to having participated in an ERP implementation.


“You, on the other hand, just spew forth your mental phlegmwads all over the place and don't have the goddamned courtesy to throw us a tissue afterwards.” -- kitten

The real reason (3.88 / 9) (#16)
by salsaman on Sat Jun 22, 2002 at 06:34:41 AM EST

Microsoft can't play nice with other companies.

Thus when they saw Java was being adopted by huge numbers of companies, they decided to get in on the game themselves. They created their own extensions to Java to try and lock people into their version. This obvious ploy didn't work, as they were then told they couldn't release their own Java derivative and still call it Java.

Then, since the ploy had failed they decided to create a rival product to Java. This time it had all of the disadvantages of Java, but without its biggest single advantage (the ability to run on multiple operating systems).

Then they cranked up the marketing machine "Java baaaaad, C# gooooood".

And to add further insult to injury, they now release an old buggy version of a JVM, just to make sure people can't use the latest features in Java.

Business is business (none / 0) (#17)
by E r i c on Sat Jun 22, 2002 at 08:20:30 AM EST

That's how it works, my friend.  How else can one explain downsizing, mergers, fraud, etc.?

I blame my past transgressions on Eminem's music. Reform number five is currently in progress.
[ Parent ]
It runs deeper than that (5.00 / 1) (#26)
by LukeyBoy on Sat Jun 22, 2002 at 12:12:13 PM EST

Microsoft is far from just a "business". They constantly break the laws set out by the United States that are there to prevent businesses from becoming a monopoly and behaving in the exact way that Microsoft has been. Take a look at this page for a beautiful summary of what sets Microsoft apart from typical businesses.

Downsizing, mergers, layoffs - these are all aspects of business. Fraud should never be one of them, and thankfully isn't.

[ Parent ]
Hah (none / 0) (#34)
by DeadBaby on Sat Jun 22, 2002 at 01:55:40 PM EST

You do realize .NET apps will run on multiple platforms right? As of yet Mono and other .NET runtimes aren't very complete but in time they will be.

Basically what Microsoft did was make other people support .NET on non-windows platforms instead of going the Sun route. This is actually better in a lot of ways, IMO. For instance, System.Windows.Forms.* can be mapped to a local UI toolkit instead of a whole new cross platform UI toolkit like Swing.


"Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity -- in all this vastness -- there is no hint that help will come from elsewhere to save us from ourselves. It is up to us." - Carl Sagan
[ Parent ]
True... (none / 0) (#38)
by salsaman on Sat Jun 22, 2002 at 02:43:45 PM EST

But what guarantee is there that they will continue to cooperate ? Given their past behaviour, many have predicted that Microsoft will wait until C# on other platforms becomes popular, then start hitting people with patents, incompatibilities, etc.; thus forcing developers on other platforms to switch to a Microsoft OS.

[ Parent ]
Sun isn't much better... (none / 0) (#39)
by DeadBaby on Sat Jun 22, 2002 at 03:04:38 PM EST

It's not like Sun can be trusted or anything. Remember their plans for a Java OS? They're just jealous they're not Microsoft. Given the chance they'd act the exact same way.

Plus, from what the Mono page says it seems that Microsoft has already opened enough of .NET up that Mono (and other .NET runtimes) could easily impliment the new features.
"Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity -- in all this vastness -- there is no hint that help will come from elsewhere to save us from ourselves. It is up to us." - Carl Sagan
[ Parent ]

Sun *is* better (4.66 / 3) (#50)
by gidds on Sat Jun 22, 2002 at 07:47:24 PM EST

To some extent, it doesn't matter whether Sun can be trusted or not.  (I think their business practices are an order of magnitude better than M$'s, but that's beside the point.)  Java isn't a closed standard: the full language specification, the virtual machine specification, and all the library specifications are freely available.  And as if that wasn't enough, the full source code is available too.  There's far more than enough information out there to make clean-room versions; some are being supported by Sun (e.g. Symbian's), and at least one (Blackdown) has been adopted by Sun.  Even the process for suggesting and deciding future enhancements is open to the community.

Compare that with .NET.  I know less about this, but I gather that although the language spec. is available, not all of the standard library is.  Knowing M$'s history, it wouldn't surprise me greatly if the much-vaunted `cross-platform' feature is never actually workable, or is kept permanently a version or two behind the Windoze one.  Sure, M$ will talk about cross-platform or security or anything that'll get people looking at them, but when it comes down to it they've never been known to let anything get in the way of promoting Windoze, and I seriously doubt that they're really about to start now, whatever they say.

Remember, Java is a known quantity.  It's here now, and its true cross-platform compatibility and security is proven.  It's had several years' worth of development, and has matured a lot in that time.  It may not make headlines in the way M$ does, but it's running an awful lot of corporate apps and back-ends.  .NET has an awful lot of catching-up to do...

[ Parent ]

Mono (none / 0) (#60)
by DeadBaby on Sun Jun 23, 2002 at 04:02:45 PM EST

Mono already runs some .NET appliations. If you write a native .NET application and it's implemented in Mono already, you're all set. If you use win32 api calls you would have to hope wine supports them or re-write those parts of your code for another platform. Part of the beauty of .NET is that even if your code isn't totally native .NET you can simply use the native api calls when you port. So at worst, .NET applications can be easily ported to another platform, at best they work with no modifcations. Not a bad deal I would say.

As far as Microsoft only supporting Windows, I would say Mono is a pretty huge step towards supporting other OS's. The project has Microsoft's blessing.
"Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity -- in all this vastness -- there is no hint that help will come from elsewhere to save us from ourselves. It is up to us." - Carl Sagan
[ Parent ]

Um, right...and pigs are flying through the trees (none / 0) (#67)
by chelidon on Mon Jun 24, 2002 at 10:20:08 AM EST

"As far as Microsoft only supporting Windows, I would say Mono is a pretty huge step towards supporting other OS's. The project has Microsoft's blessing."

I have three words for you: COM under Unix

Microsoft will support Mono just as long as it lets them claim that .Net is not yet another attempt to lock users into a proprietary path. And then they will drop it like a hot potato and make certain that it never comes to full fruition.

Any IT person with any longevity, deep expertise or insight into the field has got to be at least, cynical, if not genuinely hostile, to Microsoft's technology "standards" and "initiatives." History shows what we can expect, and more than anything else, it is that Microsoft will not be changing its spots anytime soon.

[ Parent ]
I agree. Mono is a trojan horse (none / 0) (#69)
by ajm on Mon Jun 24, 2002 at 12:16:28 PM EST

I wouldn't trust Microsoft as far as I could spit a rat. IMHO Mono is a diversion. It distracts the attention of people who could be building something original towards reimplementing Microsoft's ideas on another platform. Once Microsoft achives it's aims in enterprise penetration Mono will be dropped. I'm sorry if I sound cynical but it's pretty difficult to trust another Microsoft "standards initiative" after all of the previous ones play out the same way. Once someone or something loses your trust it's very difficult for them to get it back.

[ Parent ]
DotNet GUI classes are NOT portable (5.00 / 1) (#55)
by valency on Sun Jun 23, 2002 at 04:38:31 AM EST

I'll bet you big money that you'll never see a working implementation of Windows Forms for any OS other than Windows.

If you disagree, and somebody has already posted the exact rebuttal that you would use: moderate, don't post.
[ Parent ]
you give msft credit it doesn't deserve (1.66 / 3) (#21)
by semaphore on Sat Jun 22, 2002 at 10:26:04 AM EST

let's play with the razor

on the one hand, web services, not something that msft thought up, but very useful. - is msft going to ignore or embrace?

on the other hand, msft pondering what to conquer next, casts its gaze on the enterprise computing space, ok how do we do that? ok, we'll go for the glue.

occam says the first scenario is most likely.

sorry, i don't buy your story. i think you've been conned by the nebulous market babble surrounding .net. or else you are stretching the point to make a topical story.

that's not to say, that the ultimate outcome might not be far from what you surmise.

"you want enlightenment? stare into the sun."

I think it's the second, hence the article (none / 0) (#25)
by ajm on Sat Jun 22, 2002 at 12:01:46 PM EST

The nebulous market babble is part of .NET. It's not surrounding .NET, to some extent it is .NET. When you look closely there really isn't much there. As you say Web Services is useful but not earth shaking, virtual machines have been around since pcode so why the hype? I think the hype is cause Microsoft wants enterprise computing. I don't think they are as reactive as your first scenario implies, sometimes they do have a plan, and sometimes they implement it.

[ Parent ]
babble = .net ? absolutely! (none / 0) (#47)
by semaphore on Sat Jun 22, 2002 at 06:05:00 PM EST

(waffle alert! - ed)

and they aren't the only ones guilty of this, xml, java, ... all good stuff, but never as good as the hype. how the fsck can anyone foam at the mouth about xml? these mktgdroids, sheesh!

the little i can grok of .net is that it is mainly an evolutionary improvement which looks spectacular in some cases, but is mostly handwaving when compared to the hyperbole.

i wouldn't agree with msft being reactive in the case of web services, they're on board because they have no choice.

i think that in a lot the examples cited in the original article, the companies that did something that succeeded were lucky, not astute. i think there's a lot of hindsight in analysis and that it's usually impossible for more than a few to get it right by volition. mostly they did the right thing (wrt the premise of the article) for other reasons. and quite a few of the cited examples have not been successful.

let's take the big success - msft. i say luck not wisdom. there were 4 competing os' when the pc first came on to the market. ok, ibmdos and pc dos were the same, but the other two cp/m and the p-system had an existing user base. the market chose msft - luck, (ok, and some fancy footwork by intel and msft, and a fatal mistook by ibm.)

netscape - read joel's other article about the netscape debacle, then ask if this gels with the latest. i think that mozilla project was a desperate leap into the unknown, done because they had to be seen to be doing something. ns managed to stuff up a dominant market share so thoroughly that the only way they could ensure it's continuance, was to give it away. i don't think this was a search for cheap labour. this was sheer and utter desperation bundled in spin.

sun - amazing how the objectives of java have evolved. if you listen to the evangelists you's swear that the objectives were the same from day one. I suppose eventually this will become something usable along the lines of the original vision but i've seen some godawful stuff in the name of java.


"you want enlightenment? stare into the sun."

[ Parent ]

Not mutually exclusive (none / 0) (#62)
by sanqui on Sun Jun 23, 2002 at 06:29:07 PM EST

Good point, but your scenarios aren't mutually exclusive if looked at from a different point of view. Sure a company might commit resources to a merely useful-looking technology, but your second scenario seems a sensible enough strategy for a business with engineers and marketers to burn.

[ Parent ]
Good article (5.00 / 2) (#29)
by mirleid on Sat Jun 22, 2002 at 12:33:02 PM EST

...although I would not necessarily agree with some of your comments: basically, Web Services still have a long way to go before they can replace WebMethods/TIBCO in the EAI game.

IMHO, Web Services are nothing more than a rendition of a very old idea (RPC) with new, buzzword-compliant, tech. The really interesting part of Web Services is not the Web Service itself, but the UDDI/WSDL part, and that is pretty much in its infancy at this point. Before you can actually use it, there needs to be software design patterns/tools/whatever that enables you to find (through UDDI) a provider of a service that you are looking for according to *your* criteria (there are APIs for that, but no warranty that the information necessary for them to work will be present at the server side...for instance, you'd probably want to specify quality of service when looking up a provider, right?).

The next problem comes with interpreting the WSDL definition of a Web Service interface, and being able to, on the fly, generate the right sequence of messages and correctly interpret responses. I'm not saying that it cant be done, I'm just saying that it is just not out there yet...

I also disagree with considering Web Services as a viable way of doing EAI. EAI is about much more than being able to make services remote-invokable. For instance, the basic EAI paradigm of publisher/subscriber (that not all EAI tools share to the same extent, like TIBCO or VITRIA), and all the semantic attachments that come with it (like causal order-based delivery of messages) is simply not something that you can accomplish through something like Web Services.

Enter BizzTalk :-)...

Chickens don't give milk
It's out there (5.00 / 1) (#42)
by dennis on Sat Jun 22, 2002 at 04:51:38 PM EST

Before you can actually use it, there needs to be software design patterns/tools/whatever that enables you to find (through UDDI) a provider of a service

My company is already using it. We don't need a directory, because we do this stuff with business partners that we've negotiated data-sharing arrangements with.

The next problem comes with interpreting the WSDL definition of a Web Service interface, and being able to, on the fly, generate the right sequence of messages and correctly interpret responses...it is just not out there yet...

Again, we're already using it. Now I've heard that there are interop problems, and I can't speak to that because our partners use Visual Studio.Net just like we do. But given that, it's easy. You write a local function, add a couple lines tagging it as a webservice, and hit a button. That generates your WSDL file. Email that to your partner, who hits another button to import it, and Studio generates a local proxy function that they can call. It really is that simple. I think we're also using UDDI, but I'm not sure about that - we've got one guy who's set up all our webservices stuff. He's a very experienced VB developer, but prior to this he'd never touched XML. It took him less than a month to learn the .Net stuff and get the first services into production.

[ Parent ]

Not exactly what I meant... (none / 0) (#56)
by mirleid on Sun Jun 23, 2002 at 05:38:48 AM EST

I am sure that you can use UDDI/WSDL just fine, either within .NET or JWSDP. What I meant was highlighted by you in your post :-)

My company is already using it. We don't need a directory, because we do this stuff with business partners that we've negotiated data-sharing arrangements with.

What you are saying is that you only use this stuff with your business partners, and since you know who they are, you couldnt care less about the directory lookup part. Thats OK, but that kind of defeats the purpose of having built-in directory lookup facilities, not to mention that you probably have to make up some other process to manage what you call "data-sharing arrangements".

You write a local function, add a couple lines tagging it as a webservice, and hit a button. That generates your WSDL file. Email that to your partner, who hits another button to import it, and Studio generates a local proxy function that they can call.

Again, that defeats the whole purpose. You are supposed to lookup WSDL specs through UDDI, not mail them to the invokers. Why? Because, for one, you'll need to keep on mailing them as the interface/protocol evolves. Another thing this points out to me is that you are not using WSDL at all, you might as well have sent the MSIL proxy code to the invoking party and that would have worked as well.

Basically, what you are doing is using Web Services as a glorified RPC protocol.

Chickens don't give milk
[ Parent ]
Need examples (5.00 / 1) (#59)
by dennis on Sun Jun 23, 2002 at 03:12:46 PM EST

I sorta see what you're saying, but we can't exactly change our interface without giving our partners plenty of notice, anyway. In the end, however they get our spec, they have to code to it. And we can't make our services public, because we're dealing with confidential insurance data.

That said, I think our guy does have us registered with a directory, and that our partners use UDDI to get our specs rather than emailed WSDL, but the effect is pretty much the same - nobody can connect to us without signing contracts, setting up security, etc., and in practice there's still a lot of phone conversation involved, at least so far. It's glorified RPC, but a very easy-to-use version of RPC. For most purposes I'm having a little trouble visualizing the business use of all this automated discovery stuff - perhaps you can give me some examples?

[ Parent ]

Interesting discussion (none / 0) (#61)
by jashtalio on Sun Jun 23, 2002 at 05:02:58 PM EST

Not only do we need UDDI to mature and be truested, we also need standards to orchestrate the interaction of these services as we get standards around how we model everything as a process. http://www.intalio.com/wsci

[ Parent ]
The real issue (none / 0) (#64)
by mirleid on Mon Jun 24, 2002 at 04:12:16 AM EST

...is that, as you have mentioned, there is a fair amount of paperwork that needs to be done before you allow some company to use your service. This basically means that whatever you are exposing as a Web Service is not a public, consumer oriented service, is more like something you offer on a B2B basis. The fact that (at least the Java) Web Services spec offers a series of security related mechanisms (not to mention the ones already existing in SOAP) notwithstanding, this indicates that you would be running into one of the issues of using UDDI/WSDL, which is that there is (at least for now) no satisfactory way to integrate your own internal processes and business models (never mind your personal preferences) into the discovery process.

In regards to your question re: to business use of automated discovery, the whole point of it is to allow for consumer-oriented services to be looked up, ie, you are the consumer, you dont have any specific business ties to a provider, and you want to do use a service (like a location-based service, where you want to have the name and address of the 5 best discos in the city where you happen to be at that time), then you should be able to let the registry direct you to the most appropriate provider. No point, if you are in London, to ask that question to a provider based in NY, since the first is probably more aware and up-to-date on the London nightlife scene than the second.

Chickens don't give milk
[ Parent ]
What's the motivation? (none / 0) (#65)
by dennis on Mon Jun 24, 2002 at 06:52:34 AM EST

On the consumer side, it sounds like something that would require micropayments. We get all sorts of free services now because people are luring eyeballs, but there are no eyeballs when it's a webservice feeding into some automated consumer app. No place for your ads to pop up. Google's doing it, but that's a branded service - it's not a "search api," it's the "google api," and everybody knows it. But for the more general case, if you don't want people manually choosing services, they need to be categorized and automatically selected. There's no branding at all. I suppose your service could return a field like "brought to you by XYZ," but there's no guarantee the consumer's application will display it.

[ Parent ]
Much wider scope: printers! (5.00 / 1) (#68)
by lordpixel on Mon Jun 24, 2002 at 11:18:57 AM EST

When we used to talk about this stuff in AI/mobile agents lectures in college, the examples often included office integration.

eg, you would try to look up a printer, and your request would say

Floor:   3rd
Colour:  Must Have
Size:    Prefer Tabloid (A3)

The directory would return:

Floor: 3rd
Wait time: 20 mins
Price: 2 cents per sheet
Paper Size: Tabloid
Color: 3 color

Floor: 4th
Wait time: 30 seconds
Price: 3 cents per sheetPaper Size: Tabloid
Color: 6 color

Of course, you can see all sorts of issues - there has to be some other service running to do the billing (well, in most offices printing is "free" to employees).
The user would have to be infomed of the price, wait time and the fact they have to walk upstairs. Can you wait 20 minutes or drag your lardy butt up to the next floor?

"Real world" examples are always more complex, and to their credit the lecturers were always quick to point this out. Nevertheless a printing system that's a bit more intelligent than the current "install th driver, type in the printer name or IP address and wait 5 minutes to see if you connect" would be great. I'd gladly walk over to the other side of the floor if the printer by me has no toner, but its such a pain to configure printers at the moment that I seldom do.

In any case, the first problem is an agreed vocabularly: how do two devices say "Tabloid paper", "3rd floor" and "6 color printing process required" to each other. As I understand it, this is the problem WSDL is supposed to solve (actually, it was also one of the problem's Sun's JINI was trying to address).

Then there's the dream of no more printer drivers... extensible ways to describe a print job so you can print to any printer in the building without ever installing another driver.

The Internet commerce applications of this are certainly sexier, but the small stuff would make your life easier too - if it can be made to work. In the commerce sphere, it would seem there are huge prizes available for those who can establish this "common vocabularly".

Of course, as we've often seen in the past (instance messaging wars), the first thing said vendor will try to do is lock out any traffic from any competing client, and make sure their client talks only to their server). <sigh>

I am the cat who walks through walls, all places and all times are alike to me.
[ Parent ]

Grid Computing (4.33 / 3) (#37)
by jabber on Sat Jun 22, 2002 at 02:27:50 PM EST

"The New NET", IEEE Computer, June 2002 Issue, page 37.

The implication in the article is that Microsoft realizes the very real possibility of Windows becoming an optional, not a default OS. To remain a major player, they're looking to become the provider of choice in the area of Grid Computing (what you term 'the plumbing').

The IEEE article is more comprehensive and farther-reaching than yours, but it's still a good topic for discussion. +1 from me. Haven't heard of Grid Computing? Well, you can thank Microsoft's marketing department for stealing their thunder, calling it .NET, and advertising it as a product.

Grid Computing is all over the industry journals lately. The IEEE, the ACM, Java Developers Journal and Information Week are all devoting considerable space to the concept. .NET is just a piece of the "new revolution", with Sun's J2EE also in the mix, though in a somewhat different way.

The thing to keep in mind here is that MS has a very consistent history of Embrace and Extend. The Open Grid Services Architecture definition of a Web Services Description Language is the de facto standard that has emerged in this area, and .NET is just Microsoft's attempt to wrench control over a fundamental methodology from the industry, for itself. Would you expect anything less?

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

.NET is about Grid Computing? (none / 0) (#54)
by Carnage4Life on Sat Jun 22, 2002 at 11:41:23 PM EST

.NET being about Grid Computing is news to me and I work at Microsoft. Can you please describe what aspects of the .NET strategy or vision are indicative of Grid Computing being its goal.

The thing to keep in mind here is that MS has a very consistent history of Embrace and Extend. The Open Grid Services Architecture definition of a Web Services Description Language is the de facto standard that has emerged in this area, and .NET is just Microsoft's attempt to wrench control over a fundamental methodology from the industry, for itself. Would you expect anything less?

Oh. This is just another Microsoft-is-everyone's-favorite-Bogey-Man argument. Grid computing is an academia concept that just recently jumped on the web services bandwagon not the other way around. The Web Services Description Language (WSDL) was significantly authored my Microsoft so I'm not sure where you get off claiming that there is some embrace and extend ploy at work here.

[ Parent ]
Peoplesoft? (4.00 / 1) (#40)
by X3nocide on Sat Jun 22, 2002 at 03:11:45 PM EST

What the hell IS people soft? I've been looking in the newspaper lately, looking for interesting jobs (none I'm truely qualified for) and quite a few wanted experience with Peoplesoft. From their website they seem to be a consulting firm with some custom software in their ownership. Anyone care to enlighten further?

Heh (4.50 / 2) (#46)
by LukeyBoy on Sat Jun 22, 2002 at 05:51:51 PM EST

My friend (who's looking for a job) just asked me this the other day. PeopleSoft makes a bunch of enterprise applications for things like CRM, ERP and a bunch of other three-letter acronyms. Any of their products costs more than the average guy makes in a year, but if you're really interested in getting experience with PeopleSoft stuff there's always technical colleges that give out seminars and lessons for it.

You can probably also bullshit and say you've used it; AFAIK it's all just fairly standard web-based software.

[ Parent ]
Peoplesoft is an "Enterprise Software" v (3.50 / 2) (#70)
by sacrelicious on Mon Jun 24, 2002 at 03:29:22 PM EST

They do some of the TLA's: CRM, ERP, etc. Their main competitors are Siebel and Clarify (in CRM), SAP and Oracle (in ERP).

Peoplesoft is interesting, because they have some custom languages that are specific to their architecture (PeopleCode, AppEngine, SQR, etc). Although most of these are simple scripting, batch processing, or reporting languages, respectively, they do have proprietary syntax.

"Knowing Peoplesoft" means knowing the internal plumbing languages, and that's not exactly trivial, unless you have docs and can play with an environment. Most ppl who want this kind of experience will probably be happy if you are clueful, and have a good idea of the buzzwords, and , most importantly, know the domain (CRM, SFA, SCM, ERP, etc.)

[ Parent ]

Commoditization (none / 0) (#52)
by Ruidh on Sat Jun 22, 2002 at 11:20:53 PM EST

You assert (quoting someone else):

Smart companies try to commoditize their product's complements.

Sometimes a smart company commoditizes the product which an entrenched market leader depends on.

In 1985, Compaq was very smart to commoditize the desktop computer market. And, indeed, we're all better off now that computer hardware is largely a commodity item.

Sometimes pithy sayings are only half true.

"Laissez-faire is a French term commonly interpreted by Conservatives to mean 'lazy fairy,' which is the belief that if governments are lazy enough, the Good Fairy will come down from heaven and do all their work for them."
How was that smart? (3.00 / 1) (#53)
by Carnage4Life on Sat Jun 22, 2002 at 11:27:35 PM EST

In 1985, Compaq was very smart to commoditize the desktop computer market. And, indeed, we're all better off now that computer hardware is largely a commodity item.

Commoditizing the desktop market was not the smartest thing to have done since it eventually led to where we are today that besides Dell, no one really is making much profit out of the PC business. A smart thing to have done would have been if they had entered the market but still kept the barrier to entry high which would have screwed not only their future competitors but Microsoft as well.

[ Parent ]
What is EAI? (none / 0) (#57)
by iwnbap on Sun Jun 23, 2002 at 10:09:58 AM EST

I'm very curious about this EAI thing;  note I know very little about this but the problem seems fascinating.

As I understand, ERP systems are mostly large databases with customized schema/front ends to support things like general ledger and H.R.  ERP is hard (i.e. not doable by two guys in a garage) as I understand because:

* These systems typically have hundreds/thousands of users
* The schema/logic common to all businesses is incredibly complex (e.g. tax law for HR/payroll)
* the schema/logic within typical businesses is quite complex

However I don't see why it follows that linking two systems is hard;  if it's a case of mapping form schema to schema, they're both modelling the same thing so surely this can't be a problem.  Actually reformatting the data might be tedious, but still well within the ambit of the problem.

Problem is understanding the data (none / 0) (#66)
by ajm on Mon Jun 24, 2002 at 09:08:06 AM EST

Technically it's pretty easy to connect these systems, or at least it'd doable (when SAP R/3 started out it was very hard to do a good job of data loading). The big problem is the meaning of the fields/records being exchanged. Perhaps they both have an invoice effective date on invoice records. What does that mean? Are the rules used to calculate it the same in both systems, or would the same data entered into the two systems produce a different date? (OK, it's not normally that bad but...)

Another problem for the two guys in a garage if they wanted to produce a product to connect ERP systems is that they'd need to have running copies of the systems they want to connect installed and configured. This costs money for license fees, hardware to run the stuff, and experts to configure and manage the systems.

In the end, I think the problem becomes one that's limited not by the cleverness of the people writing the code but the knowledge of the people setting up the data mappings.

[ Parent ]
Imagine that MS wants to move into this space (none / 0) (#63)
by DCMonkey on Mon Jun 24, 2002 at 02:36:17 AM EST

They already are. They bought Navision, a maker of CRM software in May, and bought Great Plains (business accounting software) some time ago. They are also getting into POS software systems (I know, easy target :). It looks like they are targeting small and mid-sized businesses with these items, but that's where they first made it big with Windows. I'm sure they'll work up to taking on the "big boys" in these arenas someday.

.NET, the why, not the what. | 71 comments (50 topical, 21 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!