| Andrew hello.
So summarizing, its good if I publish WS's , (JSON-RPC,SOAP. .., or any other way), even if both applications, the desktop app and web app, do the same over the same database?.
Thanks
Gustavo
On May 5, 2009, at 10:40 AM, Andrew Lindesay wrote: Hello Gustavo;
With "backend" I will assume you mean "database". Yes, you are correct that you could create a Cocoa application and a separate WebObjects application which communicate back to the same database server. There are however some problems with this. The term "web services" refers to any protocol such as JSON-RPC, SOAP, XML-RPC;
- Authorisation – the client will be able to access the database directly and so authorisation of data visibility will be difficult (or in some cases impossible) to enforce. For example "Doctor Bob can see patient Sue's medical records because Sue visits Bob's department at the Eastern Hospital where he works, but can't see her contact details because Sue is not one of Bob's patients." By using web services, it is possible to leverage the same authorisation rules that drive the web interface for the API of your application.
- Database Independence – if the Cocoa client gets direct database access, are you going to be hard-wiring for a specific database product? Can you get database drivers for the C language for your current database server and the database server you may migrate to in the future? By using web services, you can leverage these advantageous behaviours of EOF.
- Network Security – Web services (JSON-RPC / SOAP / XML-RPC etc...) typically communicate using the HTTP protocol so a Cocoa client could exist anywhere on the internet. Without exposing the database to the internet, this would be impossible with direct database access.
- Validation – by accessing the database directly, validation rules in both the model as well as the java logic are by-passed and invalid data may be written to the database. By using web services, the same validation used in the web interfaces are enforced in the API of your system.
- Delegation of Complex Business Logic – If the application server contains complex business rules and the client by-passes the application server to access the database directly, it will have to re-implement those complex business rules. If you have more clients in different languages then you have more replicated code. By using web services, you can execute that logic on the application server and implement / maintain this logic once.
- Scaling – Some business process may not be able to execute on one remote client machine in an acceptable time frame and may need to be multiplexed over a number of servers to access additional memory, process closer to the database or make better use of some resource. Web-services allows you to back-haul that resource-intensive processing onto the application server.
So in general, I would tend to use an application server with web services to create a multi-user system with "fat clients".
cheers.
One question, theoretic one . If, both, the Cococa App and the WO app, are using the same servers, its worth to make a WS to interoperate between them?, I dunno if I have made myself clear; as far as I remember form school, was that WS are used mostly to interoperate different applications with different logic and back end, so if my apps are using the same back end, whatever I do in on server it will be reflected on the other app and vise-versa no?
So again my question, do I need to make such a layer with WS's ?
|