Perl & SOAP vs. ASP.net

[Spenser]

In my office, we've been working with Perl and mySQL and Linux for a couple years now quite nicely.  This week, though, we've been asked by the IS department of another branch office of our company to assist them in a system they're developing.  They have been working on developing an order management application that uses Microsoft SQL and COM objects.  They want us to drop all of our Perl and mySQL development and spend the next six months to a year working with them on their projects.  Initially, and for the first several months, we would work on creating a web interface to their objects so that other branch offices can make use of their programs over our corporate WAN.  The problem is that they won't let us use Perl and they want us to do it in Microsoft's C# with the ASP.net framework.

We told them that we belive that Perl can get at their objects using SOAP just fine.  They complained and claimed that we would also have to use ROPE (a Microsoft link to SOAP) in order to get to their COM objects.  The result of adding another two layers to the process would cause slow downs.  Whereas, with C# and ASP.net, we could link directly to their objects.

First of all, is this true that ROPE is necessary?  Second, will SOAP and ROPE add much drag to the process?  Finally, what criticisms can I make against ASP.net and C#?  Or is it not so bad?  I was caught off guard and need some intelligent responses.  I don't know much about object oriented programming and nothing about the .net systems.  So I'm at a real disadvantage in this discussion.  I think that the problems with Microsoft objects not being able to interface well with the SOAP standard is indicative of the flaws with Microsoft products.  I think the flaw in their project is that they want to be an all Microsoft project.  I don't want to stop developing in Perl and using other open-source community programs to join the corporate driven world.  We've thought of using Perl Script for ASP.net, but looking at the recent postings by Theseus, it doesn't look like an easy fit yet.

Please, I implore you, give me some ammunition.  If you can't provide assistance, then at least some sympathy.  Thanks.

-Spenser

That's Spenser, with an "s" like the detective.

[perrin]

First, Perl under ASP or CGI can access COM objects just fine and is a perfectly acceptable way to put a web front-end on them. If you don't want to use PerlScript in ASP pages, you could try out PerlEx from ActiveState.

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.

[crenz]

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. ;-)

[dws]

They complained and claimed that we would also have to use ROPE (a Microsoft link to SOAP) in order to get to their COM objects. The result of adding another two layers to the process would cause slow downs.

"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.
Resist the temptation to get into a language pissing match until they answer these questions.

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]

Take a look at http://www.soaplite.com/, they have some examples using C# and ASP. There's a lot of other information there that could provide more ammunition too, including toolkits, articles, specs, mailing lists, etc.

--
hiseldl

[digiryde]

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.

[coreolyn]

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!

coreolyn

[jk2addict]

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

[sauoq]

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.";

[eggbert]

Try and put up a quick example of what they're asking for, to show how fast/flexibly you can do it with your current platform. At the end of the day how many projects massively over-run due to bad planning/estimations of development time, etc, etc. And how many project managers end up with their testicles (or other relevent bits, depending on gender) nailed to the senior exec's wall due to afore-mentioned projects abandonment, staff losses due to dissatisfaction, etc, etc, etc.

[Spenser]

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