|Professional Services||Second Signal||Presentations||Andrew's Blog||Support|
I've been dealing with some serious analysis-paralysis with this project. Between not having a deadline and having so many choices to look at -- with virtually no experience with any of them -- I've found it very difficult to take the next step. As a result, the site is beginning to suffer from inattention and that needs to stop. I've finally decided to break off a big chunk and get working on a back end database.
You don't know how spoiled you are working with IBM Domino as a development platform until you start trying to get all the benefits it offers in any other way. Replication, directory management, indexing, and security are all built in. The combination remains, in my opinion, the most efficient and cost effective way to build dynamic web sites. What a shame that the market just doesn't care. I've spent a lot of time looking at other platforms and I'm convinced that no shelf-ready solution is going to do things just the way I want. No matter which way I go, I'm looking at a piecemeal solution by comparison. I've decided that I need to break the decision process down further and start with with the base level of my architecture. The back end database.
With the architecture choices I've made, the first step is the back end database. Everything builds up from there no matter which specific products I pick at each layer. For the database, I'm really liking what I read about mongoDB and I plan to test that out first. If I don't go that way, I'm probably going to go with a traditional relational database even if that limits my ability to store semi-structured data. In that case I'm leaning toward PostgreSQL based on what I've read, but until I've worked with it more and played with the tools I'm still considering both MySQL and MSSQL as fall backs. I'll really only pick MSSQL if I become too frustrated with other choices. My biggest concern in picking mongoDB will be deciding that it has the stability, reliability, tool availability, and industry acceptance that I really want.
Since I have an immediate need to starting using a better back end database for some other things I'm doing, I'm going to tackle this first -- even before choosing the tools for the rest of the platform.
The next layer up in the site will be the most important. I plan to build the whole thing as a set of interfaces accessible though SOAP:XML. All access to the back end data will be through these interfaces. There will be no direct web page calls to the back end data store. In all likelihood I'll be using Java servlets under Tomcat to provide these interfaces -- though that hasn't been decided yet. This part of the architecture will incorporate the security layer as well, which is why I've chosen a direction strong on object modelling. Within this architectural layer will be three layers of object modelling. The one closest to the back end database where the reading and writing actually happens; a second layer that provides access controls; and a third layer where where application logic happens.
On top of all that comes the application platforms. This will include some native Visual Studio .NET applications for running on Windows as well as whatever frameworks make sense for the various development tools I use for mobile applications and web site interfaces. A JSON layer overlay of the SOAP:XML web services may be used here as well.
The next time I write on this subject, hopefully I'll have a lot of positive things to say about the new back end database, and can make my final decision on the middle ware layer.
Please wait while your document is saved.
REST? Since you are considering using servlets anyway, seems like added
overhead of SOAP to be something that can only get in the way. MongoDb
represents everything in JSON anyway so you could probably get pretty far with
a light-weight API serviced by Tomcat.
Not trying to change any minds, just curious.