|
Cross Platform Server Application
Hi All,
I'm beginning to look into the development technologies and architectures for a future project. The project will consist of a server application that communicates with a database, processes data, and then communicates with desktop clients and a browser-based interface.
On the desktop, we're going to begin with Windows support only, but down the road we will possibly add in support for other desktop OSs. We've already decided that cross-platform desktop client development is not important to us as we will build OS-specific Desktop clients using the best toolset/languages for the given OS. (C# for the Windows client).
We need to decide on the server app. The server app needs to meet the following criteria:
- Run on Windows and Linux servers, if not others
- Interact (locally or remotely) with one or more databases of various types (Including Oracle, MS SQL Server, Access, MySQL, etc.)
- Communicate with the various desktop clients over an Intranet/the Internet
- Communicate with or expose a browser-based interface
- Provide reasonable performance (i.e. processing speed and efficiency)
- Be maintained and supported as a packaged product (Meaning that a single code base will be used and it will need to be packaged for deployment and installation by end users on various combinations of the above mentioned systems, and the implementation of the functionality (in code) must be protected within reason.)
I have plenty of ideas for this, but I'd like to tap into your collective experiences and perspectives. Assuming that you could use any language and/or technology that you wished for development, what would you prefer for the server app, and why? What communications protocol would you then use between the clients and the server app? (I'm assuming web services here, but I'm open to suggestions).
Regards,
--Josh
P.S. Any link/book recommendations on your approach of choice would be much appreciated. I'm trying to investigate everything and I figured that as a group you guys may have some different perspectives than I do for this.
JWA
Wednesday, November 26, 2003
I may be missing something here, but how about apache/php? they scale, they already exist and they are specifically designed and tested to do exactly what you require.
FullNameRequired
Wednesday, November 26, 2003
Java or PHP.
I'm not sure of the state of SOAP libraries for PHP, but I'd assume there is something workable.
Walter Rumsby
Wednesday, November 26, 2003
If you saw my thread on Mandrake and how far Linux has come -- the reason I installed it was actually to assess how far the Mono project (http://go-mono.org/) has come, and if it is reasonably viable to developer .NET web applications that are cross-platfrom compatible.
Dennis Forbes
Wednesday, November 26, 2003
In more detail. For a Java-based solution:
Web app server (one of):
* Tomcat - http://jakarta.apache.org/tomcat/
* Jetty - http://jetty.mortbay.org/jetty/
* Orion - http://www.orionserver.com/
Tomcat and Jetty are free. Orion is modestly priced and has a good reputation (Oracle's J2EE server is a branch of Orion; IBM's J2EE server uses Tomcat for its web app server; JBoss uses Jetty). All of the above are written in Java and will run on any platform with the appropriate JVM.
Database (one of)... anything really. PostreSQL is becoming a bit more popular because it is seen as more mature than MySQL, but I'm not sure how easy it is to run on Windows. Your choice will probably be determined by the framework you use and any OR mapping tool you use.
Framework. I would recommend Spring - http://www.springframework.org/ - and the (more or less) related book Expert J2EE - http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/qid=1069884045/sr=8-1/ref=sr_8_1/104-1894736-0219965?v=glance&n=507846
I recommend Spring because it provides a framework for data access (including transactions) and web MVC (and since it provides MVC supporting other UIs should be a lot easier). Expert J2EE discusses why the authour thinks Spring is a better choice than, say, Struts. Another nice thing is that Spring provides support for Hibernate.
Hibernate seems to be the most popular OR mapping framework for Java and the lead developer of Hibernate has taken on a significant role in steering the direction of the JDO (Java Data Objects) spec. OR mapping frameworks should free you from having to write a lot of data access code.
Another option for all the above is to get Oracle's 9iAS J2EE server - it comes with TopLink (probably the most mature OR mapping tool), OC4J (as mentioned a branch of Orion) and some other goodies (I don't think much of their IDE) all for around $US 5000. You'll be able to use Spring and any JDBC-friendly database too.
The strength/weakness of Java is the huge number of APIs and choice of provider for specific APIs. If you want to do something server-side, there'll be a Java implementation for it in (I would guess) 90%+ of circumstances.
Other sources of information: http://www.javablogs.com/ http://www.theserverside.com/ and Google. Other books "Effective Java", "Pragmatic Programmer", Martin Fowler books, etc.
Walter Rumsby
Wednesday, November 26, 2003
I'd recommned JBOSS if your looking for something free. We've had good luck with it.
Vince
Wednesday, November 26, 2003
At my company, we have a product that fits very closely to what you describe. The big difference is that we wrote ours several years ago, so there are some different options available now.
The server-side portion of our app is written in C++. There is some code that is conditionally compiled for Solaris or Windows. We haven't deployed on Linux yet, but if we had to, it probably wouldn't be too difficult.
We use SOAP over TCP/IP (not HTTP) for our interprocess and client/server communication.
For the client, we have a Java app, because we needed a cross platform GUI. We originally had a web-based client app, but HTML at that time wasn't robust enough to make a solid cross-platform (i.e. no ActiveX controls) client app.
All that said, if I were designing the same thing now, I'd probably go with Java on the server, because that's really where Java has flourished. That would probably eliminate the occasional problems we've run into where we had to write OS-specific code.
For the client, I'd probably do some soul searching deciding between a web client and a Java client. The Java GUI stuff (swing) is a bit of a pain to code, but it does work pretty well. For Web stuff, unless you can specify a specific browser, it's a pain to do fancy GUI stuff and have it work in all cases. On the flip side, we've had problems dealing with different JRE versions on different places we've deployed.
David
Thursday, November 27, 2003
BTW, considering that writing code in Java requires more care compared to Python, I was wondering what the advantage is in using Java to build web apps over app servers like Zope or Quixote?
Frederic Faure
Thursday, November 27, 2003
Java advantages include:
* large number of APIs
* large number of deployment options - hardware/software
* large number of providers - from single developer organisations to IBM
* quality of development tools (IDEs, debuggers, profilers, experimental things like AOP implementations)
* potential to interface with a large number of products
* large developer pool and active community
Walter Rumsby
Thursday, November 27, 2003
There have been lots of recommendations for Java, so I'm going to throw in one against. The reasons are pretty simple: miserable to install and the speed takes your computer back a couple of years in performance.
C or C++ with gSOAP can provide very fast web services to your C# clients. My exerience is with providing web services via HTTP, but gSOAP does have native support for doing it via tcp/ip as well. For speed that's probably going to give you your best results.
The gSOAP interface does take a little bit of learning to program, but once you get the hang of how it works (and rtfm) it's pretty easy. Contact me offline if you need help.
Clay Dowling
Thursday, November 27, 2003
Using C instead of Java when SOAP is your transport medium would be like putting racing tires on your tri-cycle.
SOAP is a slow, verbose protocol - I doubt there would be any noticeable difference between a C + SOAP implementation and a Java + SOAP implementation. A C-based solution would also lose the OO features of Java; present greater risk of buffer overruns and other pointer-related problems and may also present difficulties providing a cross-platform solution (i.e. Java has a pretty clear standard, cross-platform spec for server apps, I'm not aware that C does).
Walter Rumsby
Thursday, November 27, 2003
Wait, your reason for not using Java is cause its mildly slower to program? First of all, for most web applications, hardware costs are a tiny percentage of the overall costs. You really think its worth it to spend even a third as long developing a solution opposed to spending a couple grand more on hardware? Thats rediculous.
Vince
Friday, November 28, 2003
If those requirements are realy cast in stone I would pick Java. Try to control as much of the setup/runtime as possible by packing your own JRE etc.
To be honest, I think you really need to review your requirements. Having all these "portability" requirements on a shrinkwrapped product is strange.
Maybe you want to do a cost/benefit analysis between just running against a fixed platform, vs. your current anything goes approach. Support for a multiOS/multiDBMS application is going to be non-trivial to put it mildly.
Just me (Sir to you)
Friday, November 28, 2003
If you want to use XML on a web application server (multiplatform), you could take a look at our open Krysalis product - pretty similar to Cocoon2 as it provides MVC2 support.
http://www.interakt.ro/products/Krysalis/
It works over Apache/PHP and it's pretty fast still.
Alexandru
Alexandru COSTIN
Friday, November 28, 2003
Zope/Python.
http://www.zope.org
Nils
Friday, November 28, 2003
Vince,
My reason for avoiding Java is that the only place where it wins is on ease of programming, and then only in a shop with Java experience. The experience of installing it on my servers was exceptionally unpleasant, and there are some platforms where it will never run.
Since there is talk of selling this product, hardware costs do become a major issue. If the customer is forced to double or triple their hardware expense to run a single piece of software (which may also double or triple the software expense if a per-processor licensing is used), the cost for the product gets a little unreasonable. Users notice when an application is slow, they complain, and if the people complaining are important enough, the applications goes away to be replaced by a competitor.
So for an in-house project, sure, Java might be a fine choice. But for something to ship, it's a recommendation that I can't make.
As far as standards go, I've found that the differences in moving between platforms are remarkably small. There are quality build tools that are available on all major platforms (and all that were mentioned for this project). Unless the application is going to get very cosy with the operating system and use the file system for storage, code differences between different operating systems are quite small, especially for an application like this that use database storage. A programmer who avoids compiler-specific extensions can generally turn out cross platform code for a server type application.
Clay Dowling
Sunday, November 30, 2003
Use WebObjects http://www.webobjects.com/ to build the web application, and use SOAP to communicate with the clients. Both are well-supported right out of the box, and work very well.
WebObjects is 100% Java and can be deployed in most places there's a Java 2 Standard Edition 1.3.1 or 1.4.1 virtual machine. Supported configurations include Solaris, Mac OS X, and Windows; Linux and FreeBSD are very common but aren't technically supported configurations. WebObjects is also interoperable with J2EE and can be deployed in common J2EE servlet containers. It also supports virtually any database you can connect to via JDBC, including both the popular commercial databases (Oracle, Sybase, IBM DB2, Microsoft SQL Server) and Open Source databases (PostgreSQL, MySQL, SAPDB).
WebObjects makes it very, very simple to build web services using its rule-based Direct to Web Services architecture. In the simplest case, you just need to point its EOModeler tool at a database; tell it to reverse-engineer an object-relational model from the database schema; create, build, and run a Direct to Web Services application from the project template of that name; and then use the Web Services Assistant to connect to it and define some web services. It'll do everything else for you, including generating WSDL describing the service that you can hand to your favorite client-side tools.
It's really that simple to get started! And there's a lot of depth to the technology, you can customize the rule set directly (for things you can't do via the Web Services Assistant), you can write code to tweak behavior, and so on.
If you or anyone else has any questions about WebObjects, send me some email with your questions (my email address here on the forum is always valid) and I'll do my best to respond.
Chris Hanson
Sunday, November 30, 2003
 Recent Topics
Fog Creek Home
|
