An Architectural View of One-to-Many
uniPaaS is emerging as the industry’s first one-to-many application platform. We are all familiar with the one-to-many data relationship as the workhorse of relational databases. As David Remsen states: “When deciding upon how to best split data into tables we often ask "What are the logical units of the data?" In other words, what is best represented by a single row of data. It is often convenient to think of physical representations when applicable. For example, what types of information can we associate with a patient that only appears once. A person usually has one name and social security number so these can be safely placed in a table. We might add date of birth. [On the other hand] a person can have many tests. They might only have one but they might also have fifty. Thus one person might have many tests and this is represented by a One-To-Many relationship…”
A one-to-many data relationship exists when one record from one data source is related to several records from another data source; a single country in a Country data source will be linked to many entries within a City data source. This much is clear and well known to developers and users alike.
So what is a one-to-many application platform? A one-to-many application platform is an application platform designed to optimize the delivery of many applications, each of which may have many implementations. And of course, each implementation may have many users.
In the past, client-server applications tended to be bound by notions of physical location and ownership. My company owns an application server in Chicago and any of the local area network clients can use it. Using the medical record analogy above, this situation is a bit like building a doctor’s office inside of every one of your company offices just in case someone gets sick. Shouldn’t you send them to a clinic where the needs of many in the community can be served? Why monopolize the skills and equipment of a doctor for only one or two patients per day?
Even with the introduction of wide area networks, VPNs, the Internet, and the like, we still got hung up with the concept of ownership. My company bought a software license and only our people can use our software on our server, but yes they can sit anywhere on the web when they do it. Now granted, this was very liberating. Physical space dissolved when using software applications. Networking, T3, WiFi and a host of other technologies have conquered the notion of space separating us from use of computer applications.
So along comes the idea of Software-as-a-Service (SaaS) to break down another barrier. Through a concept known as multi-tenancy, the ownership barrier is broken down. Many different implementations of the same software application can exist within the same database. Each tenant’s data is firewalled from the others so that ACME Corp has no idea that ABC Corp is even using the same application. In this instance the physical servers and the software are not installed on the client computers. Only a web browser or client runtime engine need be installed, but the real application runs remotely on someone else’s physical servers. One-to-many computing is better served when the client side is capable of Rich Internet Applications (RIA).
Gradually and then all of a sudden, SaaS became a popular trend as successes like Salesforce.com bedazzled customers and Wall Street investors. The SaaS story sounded somewhat familiar to people who had been promoting hosted computing services. As the notion of grid computing sort of floundered for want of a customer base, the industry searched for a new hype cycle and found it in the notion of cloud computing. Cloud computing sort of combines the SaaS idea of Software-as-a-true-service with Software-as-a-do-it-yourself-service. Our application on your hosting server fits some people’s notions of what cloud computing is all about.
Thinking back to our medical records analogy in the beginning to explain one-to-many data relationships. SaaS is a bit like having access to a doctor’s office. You can go there and see one doctor or maybe a few, but you are pretty much limited by the skills of the doctor and the equipment in the office. Seeing a doctor is great, unless you need the services of a hospital.
A one-to-many application platform doesn’t just serve one customer and it isn’t limited to a single software supplier either. A true one-to-many application platform is independent of the underlying physical computing architecture and capable of sustaining n-applications across n-implementations with n-users. So while the application platform is unitary, it can not be bound to a single physical CPU or server in order to support its many applications, implementations and users. The architecture must be capable of application partitioning across multiple physical servers and data storage servers.