Re: [The Wisdom of Ganesh] New comment on New Home for SOFEA, Thin Server Architecture.
Mario Valente
> <mailto:mval...@ruido-visual.pt>> wrote:
>
> I insist that, from my point of view, this same SOA logic
> should be applied to all interfaces of the MVC model and/or
> all interfaces of the logic/data/presentation architecture.
>
> Namely, something like this:
>
> 1. Refactoring: Business Logic MUST be confined to the
> server. Data Logic MUST be confined to the database server.
> => The server MUST NOT contain any logic other than business
> logic. The server MUST call database services for all
> data.
> => The database server side MUST be capable of supporting
both
> API (SQL) and non-API (REST w. XML/JSON) clients.
> 2. Services: The database server SHOULD conform to SOA
>
> principles and any of the popular approaches to SOA
> (SOAP or REST)
> 3. Clients: The server logic SHOULD conform to an MVC
> architecture
> 4. Server/DB Interface: The interface between the server and
> the DB server SHOULD support:
>
> => rigorously defined data formats
> => rich message exchange patterns (not just request/response)
> => additional qualities of service (security, etc.)
>
Justin Meyer wrote:
> A few questions ....
>
Sorry for the late reply.
> *1.* When you said "Business Logic MUST be confined to the server," did
> you mean *application* server? Are you trying to separate out a
> database server and application server? Or were you just saying that
> business logic has to be on a server, but not a specific one?
>
The first case: business logic should be confined to the application
server and database server and application server should be different
"logical" servers (they might reside in the same physical server).
> *2.* Where do you draw the line between Data and Business Logic? I'm
> assuming data logic is all email values in a users table must match some
> regular expression; and business logic would be that a user registers,
> gets an email, confirms the email, then can log in.
>
> If this is true, at least with Rails/MySQL, that line can get blurred
> very easy. It lets you write complex data validations on the models.
> Those validations run on the application server. With rails / mysql,
> I'm not sure it is possible to cleanly separate out Data and Business
> logic to their respective servers.
>
Agreed, its not simple, its not easy to draw a line on what is
data logic and business logic. A certain field should be an integer.
Is that business or data logic? Most of the times it will be a
data logic validation/declaration and you should do it with a
data declaration or database stored procedure. That field should
never be smaller than 0/zero. Business or data logic? If its a
field to store someones age it would be data logic. If its a
field to store a products stock it would be business logic.
The problem remains: people are mixing up data and business logic,
sometimes due to the capabilities/deficiencies of the tools involved,
and there should be ways to guarantee/enforce separation.
> *3.* Are you proposing that the Data server MUST provide an SQL and REST
> api? I'm not sure about this.
>
I think that the data server should (as in must) provide a
REST API. A SQL API would be optional.
Is the goal to provide 2 types of
> APIs/Service layers? The api's would be:
>
> * Data: A data API for 'super' privileged application developers to
> create their own business logic for the data.
> * Business: The business API's that run from the Data APIs.
>
> I guess it comes down to what you want to see these specs moving people
> towards. Personally, I want to push people towards creating reusable
> (final?) services - finally delivering the promises of mashups, SOA, and
> orchestration. Although layered Data/Business services are great idea,
> I think that the Business services are more important and might suffer
> from any other additional competition.
>
You do have a point. My opinion is that having the same type of
interface/API for both the business layer and the data layer would
be important for a full service oriented platform. For example, other
applications, with different business logic, might want to access
some other applications data. I think that this should be done in
a REST way (as for business services), but I do agree that competition
problems might arise.
-- MV
Peter Svensson
Consider GAE, which has an integrated storage model (and 10gen (and Persevere SSJS)). I am of the opinion that the traditional stored-proc, manually partitioned tables, et.c. separate data services are on the way out anyway. I think it will soon be like hand-coding assembly to get the last few cycles out of an algorithm.
But again, that's just me :)
Even if we would still need to cater to a separate data layer, logically, for the next 20 years, the most important issue today, is I think to do whatever we can to make people (and especially newbies) to stop dig themselves into the server-side templating hole, and get stuck there.
I understand that we need to create a model which is generic, but as such I think that it has more to win in defining only two endpoints. Then any two next other endpoint might be defined equally.
Cheers,
PS