Well, its been almost two years since I have been working for Accenture and its clients. Today, I just had a thought about the kind of projects the Computer Science students of my college used to do. The common types include all these “Management Systems” like Inventory, Hospital and so on. During the college days how people do or rather get forced to do is to just make a gimmick out of them with basic C/C++ on a command-line interface and making a what they call “Menu driven program”.
Now that I have been in the industry for some time and have learned and developed or been part of the development of solutions to a number of clients, I thought how about resurrecting an old school program that I made using what I have seen/learned over the years. Lets be honest here. I was gettin bored having nothing to do and this came out as a result of 5mins of scribbling on a paper.
Heres AK’s Library Solution. At this point I’m not sure which library can afford such a solution. Maybe the Library of Congress can. No idea. Anyways here goes :
I have just made a high level architecture diagram I just drew up here :
The following are the features I had in mind :
- Front End Application for Librarian(possibly a CRM based)
- Online Web portal for customers – which would allow customers to do many things like manage his account, reservation of books, online payment, etc.
- A lot of backend stuff including databases, Archives.
- Loggers, Report Generators for audit purposes – based on a batch processing system.
- Access mechanism for internal users for maintenance, audit, etc.
All the databases can use Oracle’s Database system. We have database servers everywhere and oracle’s DB is great for high performance apps with high availability. The Core DB is where we have our main library data, including customer data. The Web DB and Lib DB would just retrieve the data from core DB via DB links to be in turn taken up by the WebApp and LibApp for presenting to the user.
Internal users include developers, administrators and whoever working the library that has no connection to the outside world who want to monitor, review and perform similar tasks and even maintenance to the system. They access the system thru a jump server. The purpose of the jump server is to log their activities for a trace purpose, which very helpful for developers and maintenance specialists to identify human errors to fix them. Also, internal can be applications too rather than people logging in manually.
The internal statistics block is a repository of the logs and reports generated by the logger and reporter. This server is expected to have enough storage to host data for at least a week or month, beyond which the data is moved to the Archives. Also there has to be a way to retrieve archive contents when required.
So, what do you think? Any comments suggestions are always welcome.
Anoop,
I think you are making it too complicated as far as hardware. Why all the extra DB servers (Web DB, Lib DB, Reporter DB)? The web apps should just have appropriate access to the core DB server.
Ed
They say around here that its for better load handling capabilities hence performance.
Like I said, this is not for the city college library. If it was, I would have this whole thing clustered on a single server or max two, depending on how much of this they want 🙂
If you have the biggest library on earth with millions or more customers, I would go for this split-up.
This is actually based on what I have witnessed here. The only difference is that it was a billing system for a telecom company rather than for a library.
Like I said, just crazy stuff 🙂
and that billing system is much larger compared to what I have drawn. A small idea I can give you is that the single core DB thats there for me is a collection of 22+ DB servers there(and there are backup servers to take over if any of them die out). And for the web-app, each section of the web-app interacts with a different web-app DBs which in-turn interact with core DBs via DB-Links.
One word. Overengineering. Industry style doesn't mean that you over complicate stuff. And using DBLinks to provide real time data is a very very bad idea and doesn't scale at all.
@ Rajiv
So far I have been seeing this over-complication being implemented everywhere here and thats precisely why the applications being developed runs much faster in your local environment than in production 🙂
Its funny to see how people simply put up more and more stuff to extract more money out of the client(usually just managers with no technical understanding who can be convinced simply by a chart and/or a ppt presentation) and as long as the client remains to be ignorant you know what happens 😀