The boredom is killing me slowly here! How can four weeks pass so fast! Well at least I had a lovely vacation. Hope you all are enjoying yours!
Im sitting here now designing some new parts of the application here on my current assignment on IKEA. It really strikes me how astray the mainstream design patter has gone today. As everyone else IKEA uses a three tier solution but with fat VB clients. And as commonly the middle tier diminishes into a data-access layer and the business logic pops up as scattered foul smelling bubbles in the client.
Why is this? Because it has to be there! In this case formulas have to be applied to data and shown in real time for the end-user. The end-users must be able to change onscreen values and other displayed values must be recalculated and displayed as close to real time as possible. And the main application value lies in these formulas and they are arguably the core business logic in the application. Should we place those calculations on the server? Just for the reason to have all business logic there? The result would be an unacceptable long response time for the end-user and a ridiculous increase of network traffic. So from the end-users perspective it is to say the least undesirable to place this kind of logic on the server. And even if we developers have troubles accepting it sometimes, it is the end-users that we are serving.
So why do we want the business logic on the server? For our formulas it more or less sucks! All though there are some serious points placing it on the server. I can see three main reasons.
The first is a central place of update and distribution. These formulas are definitely subject to change and if the change requires a reinstallation of the clients we really loses a lot of flexibility. This is not really a big problem when smart clients are used as we normally do when working with the CEL framework. As I see it distribution is the reason of all reasons to why we do as we do today with the business logic in heavy clients and it has an obvious source in the thin clients design. In reality we just threw away our own history and just adopted the thin client design. The main point and advantage with thin clients compared to heavy ones have been distribution. But this is not really a problem anymore for heavy clients and heavy clients are still the way to go when you want to work seriously demanding application. That is a good thing with IKEA, they arent trying to make the cashiers work in Internet Explorer (thank god for that). But in some situations updates must be done on a minute or second basis and smart clients updates are normally made only on a daily basis. This is however relatively rare, but when it happens we can not rely solemnly on smart client technology to distribute the business logic to the clients.
The second reason is security. If the formulas I have mentioned where the wholly grail of IKEA we wouldnt really want it to exist even if only in coded form in the client. This is not the case here but it is a valid reason to place it on the server. Say for instance that we wanted to encrypt some information it would not be wise to include the private key to all the clients in the system. In such a case encryption should certainly be performed on the server.
The third reason is when performing sequential multi-step updates. What? The classic example is transferring money from one account to another. Typically these are operations that involve persistent data updates that should be performed inside a single transaction. The reasons to do this on the server side are performance and data consistency. These operations should be performed in transactions and transactions should really not be opened on the clients side since they the networking will cause the transaction to take like a thousand times longer and during that time data will likely be locked for other end-users. We handle these quite well in a very simple way in CEL with the data service transactions. The transactions are however not enough in many instances like the account transaction example. In such cases a service must be made and an action must be made.
I have heard developers stating performance as a fourth reason to place business logic on the server. Generally this is in my opinion more of an anti-reason to place it on the server. The exception is the sequential multi-step updates I mentioned above. In all other cases I can think of it is more desirable put as little load on the server as possible. Ive been working in places with absolutely horrid performance problems due to server workloads that just could not be met. And server hardware is very expensive while client hardware is from an application perspective more or less free.
Conclusions? Well I think that our service layer is pretty good. It covers the formula example well. The formulas would be placed in a service and accessed from the clients and it would be transparent for the client where the logic would actually be performed. The logic would be server controlled, it could be denied to unsecure clients and it could be updated fairly easy although relying on smart client technology.
A number of things could be done and improved though. Here are some thoughts
1. Services should be declared or published as distributed or remote. Distributed services should be run on the client side while remote ones should be accessed transparently using proxies on the server.
2. The service provider should have an integrated class-loader to transfer new classes from the server to the clients. This would be very powerful and allow mediate updates of the logic on the clients. New services and logic could be added without recompiling or even restarting either the clients or the server. It would also allow different logic to be delivered to different clients
3. It should be possible to update clients by pushing out updated services from the server. These would make it possible to make second based updates of logic on the client.
4. Possibly custom action steps should be possible to include in the current data service transactions. We use proxy data values today to handle account-transaction scenarios but if the whole transaction structure was action based it would be more flexible. It would also lead to other advantages as rollback possibilities, undo functionality and CEL based transaction handling (usable for our file and memory data services).
5. Possibly the data services should be expanded to a model service concept where all access of data would be treated as actions that were that wouldnt differ from business logic actions. This could be very powerful but requires a lot of thought. Today we generate building (Lego) blocks of data objects and views that can be snapped together in an easy way but the business logic is left for manual coding. By adding business logic actions as similar blocks we would go all the way. The work for that has already started in CEL but is not completed and if completed maybe we should rethink what a data service really is since it provides a lot more then just data.
Did anyone of you have the stamina to follow me this long? Any comments regarding business logic? Do you have other examples or thoughts that we should consider? I think that the kind business logic/data access structure that CEL uses is what developers really want today, but they dont know about it, they just do what everybody else is doing and whine about. This is surely the case here. Maybe this is an angle to use market CEL in the communities? Your thoughts please?
Regards /Dennis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi everyone!
The boredom is killing me slowly here! How can four weeks pass so fast! Well at least I had a lovely vacation. Hope you all are enjoying yours!
Im sitting here now designing some new parts of the application here on my current assignment on IKEA. It really strikes me how astray the mainstream design patter has gone today. As everyone else IKEA uses a three tier solution but with fat VB clients. And as commonly the middle tier diminishes into a data-access layer and the business logic pops up as scattered foul smelling bubbles in the client.
Why is this? Because it has to be there! In this case formulas have to be applied to data and shown in real time for the end-user. The end-users must be able to change onscreen values and other displayed values must be recalculated and displayed as close to real time as possible. And the main application value lies in these formulas and they are arguably the core business logic in the application. Should we place those calculations on the server? Just for the reason to have all business logic there? The result would be an unacceptable long response time for the end-user and a ridiculous increase of network traffic. So from the end-users perspective it is to say the least undesirable to place this kind of logic on the server. And even if we developers have troubles accepting it sometimes, it is the end-users that we are serving.
So why do we want the business logic on the server? For our formulas it more or less sucks! All though there are some serious points placing it on the server. I can see three main reasons.
The first is a central place of update and distribution. These formulas are definitely subject to change and if the change requires a reinstallation of the clients we really loses a lot of flexibility. This is not really a big problem when smart clients are used as we normally do when working with the CEL framework. As I see it distribution is the reason of all reasons to why we do as we do today with the business logic in heavy clients and it has an obvious source in the thin clients design. In reality we just threw away our own history and just adopted the thin client design. The main point and advantage with thin clients compared to heavy ones have been distribution. But this is not really a problem anymore for heavy clients and heavy clients are still the way to go when you want to work seriously demanding application. That is a good thing with IKEA, they arent trying to make the cashiers work in Internet Explorer (thank god for that). But in some situations updates must be done on a minute or second basis and smart clients updates are normally made only on a daily basis. This is however relatively rare, but when it happens we can not rely solemnly on smart client technology to distribute the business logic to the clients.
The second reason is security. If the formulas I have mentioned where the wholly grail of IKEA we wouldnt really want it to exist even if only in coded form in the client. This is not the case here but it is a valid reason to place it on the server. Say for instance that we wanted to encrypt some information it would not be wise to include the private key to all the clients in the system. In such a case encryption should certainly be performed on the server.
The third reason is when performing sequential multi-step updates. What? The classic example is transferring money from one account to another. Typically these are operations that involve persistent data updates that should be performed inside a single transaction. The reasons to do this on the server side are performance and data consistency. These operations should be performed in transactions and transactions should really not be opened on the clients side since they the networking will cause the transaction to take like a thousand times longer and during that time data will likely be locked for other end-users. We handle these quite well in a very simple way in CEL with the data service transactions. The transactions are however not enough in many instances like the account transaction example. In such cases a service must be made and an action must be made.
I have heard developers stating performance as a fourth reason to place business logic on the server. Generally this is in my opinion more of an anti-reason to place it on the server. The exception is the sequential multi-step updates I mentioned above. In all other cases I can think of it is more desirable put as little load on the server as possible. Ive been working in places with absolutely horrid performance problems due to server workloads that just could not be met. And server hardware is very expensive while client hardware is from an application perspective more or less free.
Conclusions? Well I think that our service layer is pretty good. It covers the formula example well. The formulas would be placed in a service and accessed from the clients and it would be transparent for the client where the logic would actually be performed. The logic would be server controlled, it could be denied to unsecure clients and it could be updated fairly easy although relying on smart client technology.
A number of things could be done and improved though. Here are some thoughts
1. Services should be declared or published as distributed or remote. Distributed services should be run on the client side while remote ones should be accessed transparently using proxies on the server.
2. The service provider should have an integrated class-loader to transfer new classes from the server to the clients. This would be very powerful and allow mediate updates of the logic on the clients. New services and logic could be added without recompiling or even restarting either the clients or the server. It would also allow different logic to be delivered to different clients
3. It should be possible to update clients by pushing out updated services from the server. These would make it possible to make second based updates of logic on the client.
4. Possibly custom action steps should be possible to include in the current data service transactions. We use proxy data values today to handle account-transaction scenarios but if the whole transaction structure was action based it would be more flexible. It would also lead to other advantages as rollback possibilities, undo functionality and CEL based transaction handling (usable for our file and memory data services).
5. Possibly the data services should be expanded to a model service concept where all access of data would be treated as actions that were that wouldnt differ from business logic actions. This could be very powerful but requires a lot of thought. Today we generate building (Lego) blocks of data objects and views that can be snapped together in an easy way but the business logic is left for manual coding. By adding business logic actions as similar blocks we would go all the way. The work for that has already started in CEL but is not completed and if completed maybe we should rethink what a data service really is since it provides a lot more then just data.
Did anyone of you have the stamina to follow me this long? Any comments regarding business logic? Do you have other examples or thoughts that we should consider? I think that the kind business logic/data access structure that CEL uses is what developers really want today, but they dont know about it, they just do what everybody else is doing and whine about. This is surely the case here. Maybe this is an angle to use market CEL in the communities? Your thoughts please?
Regards /Dennis