The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

crossplatform serverside component

I'm looking to implement a serverside component for web servers that will make a (eventually, several) fairly simple SOAP and/or REST webservice call, provide some failover to a second webservice URI, and provide logging/testing capabilities.

Is there any one "right" language to write this in these days? The target market is ecomm, it could be dedicated servers, it could be shared hosting, VPS, cloud.

I'm guessing C++/ISAPI with a SOAP and/or REST library is the way to go here, but it's been a while since I've looked into this kind of thing.
Andrew Badera Send private email
Thursday, October 09, 2008
 
 
Hmmm... the combination C++/ISAPI sounds very low level, with a significant risk of being stuck on Windows with the Microsoft C++ compiler and IIS.

I would suggest Java, because it is a pretty comfortable platform to use with respect to both REST and SOAP, with a ton of deployment options as well.
Tov Are Jacobsen Send private email
Saturday, October 11, 2008
 
 
OP, I agree that ISAPI is too low-level and not a good fit for your requirements. It's not cross-platform -- you're basically limiting yourself to IIS on Windows and Apache on Windows. Also, shared hosting providers generally don't allow ISAPI modules.

Beyond that, it's highly unusual to see web work done in C++ these days. It just doesn't give you anything that compensates for the increased development time and security risk.

If you need to be cross-platform, Java and PHP are the only reasonable choices. If you need to run on inexpensive shared hosting, PHP is the only reasonable choice.
clcr
Sunday, October 12, 2008
 
 
Difinitely Java.
howdy
Monday, October 13, 2008
 
 
This component needs to be callable by .NET, by PHP, by Java, by Ruby, by whatever. This component calls out to my web services, and renders content on the client site.

I think in the end the only true answer is to write and maintain components in each of my target languages/frameworks. Maintainability is going to suck.
Andrew Badera Send private email
Monday, October 13, 2008
 
 
First off, the business answer is to either narrow your focus or take advantage of the fact that you're talking about several different markets with their own pricing policies.

The only way you're going to write code that's callable from all of those languages is to go with COM, and then only on Windows and only with some difficulty both on your part and on the part of your users. Wrapping a COM object well enough so that it feels native to callers and they don't get any whale guts on them when things go wrong is a challenge. More importantly, if you go with anything other than pure PHP then you give up the PHP shared hosting market.

Which language is used most by the market you're targeting?
clcr
Tuesday, October 14, 2008
 
 
Our language of choice is WSDL. We carefully designed and defined our functions and messages in WSDL then ran it through the wsdl2java tool in Apache Axis (they also have a C++ tool). It generated the client and server stubs.

The client stub is called from the web server, the server stub went to our application server where it calls our API objects. In our case the web server is using JSP, the backend is Tomcat and Java

There is a slight overhead on CPU for the extra message wrapping/unwrapping but you get great front end/back end independence (i.e. use Java at one end, C++ at the other)

Visual Studio has tools to generate stubs from WSDL. As an example we built a Visual Basic client that connects to our backend Tomcat server. Just specify the URL to the WSDL and it gives you a module with the methods.
jz Send private email
Tuesday, October 14, 2008
 
 
Here's the problem: I'm dealing with partners who need essentially no barrier to installation and use. They might be small shops lacking expertise, or they might be top 50 retailers whose IT departments are recalcitrant to add another project to the queue, or any more maintenance obligations to their budgets.

I can't narrow my focus, I need to address the top 5-6-7 or so most commonly used languages or frameworks in ecomm, which means PHP, ASP.NET, RoR, Python+Django or Pylons, probably Perl ... and probably in that order of priority.
Andrew Badera Send private email
Wednesday, October 15, 2008
 
 
I tend to agree with you on the language choise. Have the core in C/C++, with all the functionality to the outside world in C exported functions. Then you can compile it for Linux, for Windows, for Mac, for mobile. And then write bindings for any of languages you plan to support. Want Java? I am sure Java can call C functions. PHP? C#?

Implementing the core again and again for each language is too much of a hassle.
Goran Burcevski Send private email
Friday, October 17, 2008
 
 
I've come to realize that I can implement every currently-imagined aspect of the widget, except for logging, using JavaScript/AJAX/CSS/XHTML/etc. It can manage partner preferences like display styles and moes, do a login, get a token, check to see if the partner has turned the service on or off, check to see if it's in A/B test mode, and whether it's in A or B state and then display the widget, or not, based on test state, check to get default values and other things the partners are generating on their end now, but could be controlled from a dashboard on our end. And if the service call fails, it can try a backup server as well.

The only thing it would be missing would be local logging to disk or etc.
Andrew Badera Send private email
Monday, October 20, 2008
 
 
Why not use a REST setup like yahoo maps or something? Just format a url with the arguments to the service, fire it off in an http connections, and retrieve the repsonse as xml?  Most all languages have decent xml parsing capabilitie nowadays.

Saturday, October 25, 2008
 
 
Obviously if I'm going JavaScript, and I'm talking about doing multiple steps after a pageload in JavaScript, I'll be using AJAX, and probably REST. But thanks for the obvious redundancy ...
Andrew Badera Send private email
Monday, October 27, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz