From http://www.psdn.com/library/thread.jspa?messageID=8212—
>>
Let's take that debate in a new thread
For me it's pretty clear where the AppServer fits in. When you want a thin client, meaning as few lines of business logic as possible deployed on the client, you need a server that can service application requests. For OpenEdge this means an AppServer when you want to implement business logic as ABL-code.
All services that you require in the client have to be exposed by the AppServer. There could be more services for other types of clients of course. Exposing a service means exposing a weldefined and stable contract (behavior and data). A service should not trust any incoming requests, so it should validate all data. You should only expose those services that are capable of keeping the integrity of the system intact. Compare it to exposing the raw database to a "customer maintenance service". Both services can update the database, but only the 2nd service we trust.
Once you're inside the AppServer's boundary and the request has been validated, you might reduce the trust level. Now the internal object model comes into play. It's about transactions, entities, data transformation (from class instance/temp-table to database buffer and vice versa), database access, etc.
It isn't as if I am doubting that
AppServer is useful, just that I a fuzzy about where it does and
doesn't have a role. As historically used, it provides an interface
between a remote client, whether ABL or some other technology, and
the server. If we have that kind of client in our new application,
i.e., not a browser, then to be sure it seems likely that we will
use AppServer to make the connection. But, does it have any other
role? That's what I don't know yet. AppServer, more than anything
else, has taught us about the virtues of statelessness for
scalability, but, it is also clear that statelessness presents some
issues, some tradeoffs, so we need to be judicious in where we do
and don't strive for statelessness in our components and services.
This is one of the reasons I think multi-threaded sessions are so
important since it means that the main controlling thread can be
stateless, but state for long running in-process activities can be
maintained in the threads. The question is, how does one session
avail itself of the services of other sessions. This might have
something to do with AppServer and it might not since it is an
intra-server issue, not a client-server one. For server to server
connections, I think there is a strong argument for the use of
Sonic because it has all the right bits. And, no reason to think
that it won't also serve for service to service connections within
a server as long as we are talking about services of the type and
level which one typically associates with SOA. But, what do we do
for smaller scale connections, i.e., the kind of thing that one
would ordinarily deploy within a single JVM, were we writing in
Java? Without a multi-threaded AVM, it seems like we need to
provide a way to strap together multiple sessions in order to
provide multiple lines of execution within a single logical
service.
As historically used, it
provides an interface between a remote client,
whether ABL or some other technology, and the server.
If we have that kind of client in our new
application, i.e., not a browser, then to be sure it
seems likely that we will use AppServer to make the
connection.
I agree.
But, does it have any other role?
I don't think so.
That's what I don't know yet.
AppServer, more than anything else, has taught us
about the virtues of statelessness for scalability,
but, it is also clear that statelessness presents
some issues, some tradeoffs, so we need to be
judicious in where we do and don't strive for
statelessness in our components and services.
The "statelessness" only applies to the service layer were the request is received, potentially "massaged" and passed down to the server side, internal, object model which encapsulate data and behavior, thus maintaining state for the lifetime of the request. I see no need to pass the entire context from one method call to another all the time.
This
is one of the reasons I think multi-threaded sessions
are so important since it means that the main
controlling thread can be stateless, but state for
long running in-process activities can be maintained
in the threads.
Were does this need for multithreading come from? Sure I can see it's beneficial to split certain requests in carefully designed parallel requests, but most of the logic isn't suited for that.
Because the scope of a session is so limited without it. With
multithreading, a stateless primary service component can listen to
requests on the bus and, when one is received, can identify the
type of work that needs to be done, fork off a thread to process
the request and return almost immediately to listening. When the
process completes, it triggers the main process which takes the
results and passes them back to the bus. This allows a single
service to be simultaneously process multiple requests without
being blocked. Doing that without multi-threading seems like it is
going to take some pretty clumsy or heavy-weight interfaces.