Second, Microsoft swears up and down that any idiot can turn their COM objects into web services, so your IS team should be able to do it easilly. Their concerns about performance may be valid though if this application requires very fast response times, since SOAP is not very fast (generate XML, send it over HTTP, parse the XML, generate more, send it back over HTTP, parse again).

But the silliest part of this is that they want you, who volunteered that you "don't know much about object oriented programming and nothing about the .net systems" to learn a new strongly-typed OO language, not to mention the COM model, just so you can put a web interface on their stuff. If they insist on staying with an all-Microsoft stack of products, ASP with VBScript would be a more obvious choice.

But the silliest part of this is that they want you...

Yes, I agree. People don't take into consideration that "speed" not only refers to execution speed, but also to implementation speed.

But the main problem is: Decisions like these are often based on management directives and gut feelings, rather than facts. I fear that even if you have the better arguments, it will be hard to turn the tide. It is amazing how perfectly willing a company can be to waste their employee's time.

To improve your working conditions, maybe you can get your boss to read The Hacker FAQ. ;-)

"It'll be too sloooooow" is a classic stalling technique. The way to deal with it is to force them to get specific.

• How fast do they need to it be?
• How many requests/second do they require, and with what latency.

Once you have numbers, prototype and benchmark. Then prepare for the next objection. Rinse, lather, repeat.

Keep a list of the objections they raise, and how you counter those objections. That might come in useful if they give up raising objections in favor of just insisting you use their tools of choice.

--
hiseldl

I have yet to work in a shop that goes all M$ for anything but political or M$ marketing reasons. Anyway you slice it, it becomes religion, not logic.

I would try to find out why they are so stuck on M$. The battle you are really fighting probably has nothing to do with the obvious technical issues. It probably has a lot more to do with someone's nose up someone's dark side.

One contract I had, the programmers were so arrogant (and ignorant) that they simply dismissed any and all evidence counter to there position as uneducated rubbish. My mistake was to continue to pursue reason -run the tests see if the given conclusions from real world experiences pan out. All that did was make people upset. Though in the end, my program way outperformed expectations, and provided unbelievable upgradeability, I proved the wrong people wrong. I won my battle, lost my war.

The moral of my story is a paycheck is a paycheck, and a good reccomendation from an idiot is still a good recommendation. Tread lightly, do the project, add a skillset, and move on. Good luck.

Not knowing the scope of the application this may or may not be 'ammunition'. But it might help to inquire what they intend to do if down the road they want to interface with an app or object outside of the current platform. Say for instance a Java object or C++ objects that come from a Unix Application. With the SOAP solution you and potential clients are already set to rock. With their solution you are locked in...

And the Gate's tabernacle Choir Sings,
Forever, and Ever!,
hallelujah, hallelujah!
For you shall pay forever and ever.
For you shall pay forever and ever.
hallelujah, hallelujah!

I've been doing ASP/VB/SQL/COM/MTS/bla ever since it hit the scene, and before that it was or database driven scripting software. (Anyone ever heard of Searchlite Software and Spinnaker?)

Now that NT4 is going away, and soon, ASP is going away, then W2K, etc, I've been doing a lot of thinking about what languages/servers I used to develop in. Here's my response to a discussion a while back, my feelings are the same, and this is why I'll never use ASP.NET:

------------------------------------------------

I too have been embroiled in the ASP/IIS/MSSQL/COM/MTS stuff ever since it came out. Before that, I was using a product by Searchlite software called 'Spinnaker' that did most of what ASP was all about; dynamic pages with DB access sans resorting to true CGI.

It's where I make my living and pay the bills, and where I feel most comfortable in terms of development. Development time (for me) using ASP/IIS/MSSQL/etc is quick and painless because I've done that stuff for so long.

Every site I currently maintain is some way is an IIS/ASP/COM/SQL solution, a problem I wish to change at the next opportunity for reason below.

Like you, I haven't dug into .NET past reading some articles. While I think Joel presents some great points, for me, it still doesn't cut it. I _AM_ impressed by what .NET is and what it can be. It is without a doubt a great set of ideas and features with a lot of thought behind it. But no matter how good it is, it's still one thing for me: Platform Lock-In.

Sure, .NET _may_ eventually run on FreeBSD ala the CLR, but I won't place any money on that given it's creators, nor given how Java still isn't what it's hyped to be.

The more projects I do, the more time I invest in software creation (or site creation), the more I want to get the most bang for my buck in return, and so do the clients paying for my development time and results. Clients have already paid once for me to build their site/software. In trusting me to do that for them, I think they have also trusted me to plan for their site's future, including where it may or may not run, or from which OS it may be run on.

If they want to move to a new ISP, or even new server OS, they should be able to take that product with them, not repay for a conversion to another OS/platform. For that matter, I don't want to convert anything either as that isn't a good use of my time. Developing in ASP/IIS/.NET means lock-in with no reusability. Developing new sites in PHP/Perl/Apache/ Cocoon/AxKit/etc means non-lock-in with great reusability.

Choice #1 Develop in .NET (and for me now, ASP/IIS/MTS/MSSQL), and have it run in 1 place; Windows, or

Choice #2 Develop in PHP/XML/ Cocoon/AxKit/Perl, and having it run many places; BSD, Linux, HPUX, Windows, MaxOSX?

To me, the choice is becoming more clear everyday.

I'll take smart portable development over quick unportable development any day, and I believe even clients in a hurry to see results would agree when they fully realize their investment is a reusable product they own and can move, and not a windows only service they will have to pay for (via conversion) again when they want to move elsewhere.

By developing in ASP/IIS, I have locked clients into using me, hosted by me (or a derivative) or my server, which makes me just a guilty as M$ at 'the lock-in' game.

Let's not forget to mention that the price I pay for a windows server license could be better spent on a couple more servers running a free OS alternative, which is only a possibility for non IIS/ASP sites.

With the advent ot Apache 2.0, were it is 'production quality' on win32, there isn't going to be any excuse for me any more. Pick a platform, and you can find PHP/Perl/Apache/Cocoon/ AxKit/Mason/TemToolkit/etc in some form or another; try that with ASP/ASP.NET/.NET

But I digress. My main feedback was that while .NET is great compared to ASP/VB/C, and quicker, it still sufferes from the only-runs-on-one-platform syndrome.

Just for my sanity, I went back and reread Joels post on .NET development and direction for them. If I were in their situation, I would probably do the same for _client-side_ software development.

.NET is faster, easier, and smarter for client-side apps, but I wouldn't touch it with a 10 foot pole for server-side development from a site perspective.

For that matter though, even if I were making a client-side app, I'd still be inclined to have the GUI (written in .NET) be nothing more than a interface into a local/remote server via XML-RPC/SOAP; where by the XML-RPC/SOAP server stuff would still Apache/PHP/Perl/etc so it could migrate freely.

Funny enough, that's probably why I leaned towards server-side development instead of client-side apps...I couldn't stand the thought of spending time on an EXE that can't go anywhere, while a site could run cross platform, which is after all, the goal of SGML/HTML/*ML markup to begin with.

Now in all fairness, I'm not eating my own dog food in this matter. I've got plenty of ASP/IIS sites that I can't convert do to time, or that can't get rid of all together because the clients can't find another ASP/IIS host within reason, although, PHP/PERL/Apache web hosts are a dime a dozen, at least around here.

But you can but your last dollar that I will not develop/host/deploy another new site that can't be moved about freely via more open software instead of windows only ASP/IIS/.NET
------------------------------------------------

Just for giggles, read this: Building a Large-scale E-commerce Site with Apache and mod_perl. While completely irrelevant, I has some good traffic numbers. Now imagine those numbers under IIS/ASP/ASP.net? Now stop laughing. :-)

-=Chris

Choice #1 Develop in .NET (and for me now, ASP/IIS/MTS/MSSQL), and have it run in 1 place; Windows, or
Choice #2 Develop in PHP/XML/ Cocoon/AxKit/Perl, and having it run many places; BSD, Linux, HPUX, Windows, MaxOSX?
To me, the choice is becoming more clear everyday.
I'll take smart portable development over quick unportable development any day,

And you don't have to give up "quick" either; at least not once you have some experience. PHP and Perl are both great for rapid development!

-sauoq
"My two cents aren't worth a dime.";

Thanks for all the comments.  They were all very helpful in numerous discussions we've had in the past few days.