Components in this category are intended for use as part of the Common Infrastructure of the OERA layering.
Bruce Gruenbaum:
The Auditing Service logs access and changes to data and stores away the state of the data at the time that an event took place. It is subtly different from logging in that logging is about keeping track of the fact that things happened whereas auditing is about keeping track of exactly what happened.
Thomas Mercer-Hursh:
And, given the availability of database auditing facilities, there is a question of what constitutes an auditable event, especially in relation to a logable event. I'm not 100% sure that there is a clean separation versus the notion that there are some log events which have interest for auditing.
Initial content adapted from an exchange on PEG.
Bruce Gruenbaum:
The Authentication Service is responsible for authenticating a user when the session starts up. All it does is determine that the user is known to the system and that the user's credentials have been authenticated. In most applications, the Authentication Service is a façade that allows implements
its authentication through an LDAP or other authentication service. The Authentication Service also provides the Connection Factory and other services with the credentials they need to authenticate the user of this session against other targets.
Thomas Mercer-Hursh
Are non-humans, i.e., services also authenticated and how?
Does this return a token which is then used to indicate that the current session is authenticated?
Initial content adapted from an exchange on the PEG
Bruce Gruenbaum
The Authorization Service is responsible for verifying and applying permissions and policies to the user that is logged in. Again, most of its implementation resides in an LDAP or other service, but the Authentication Service allows for this to be abstracted so that LDAP can be swapped out for something else.
Thomas Mercer-Hursh
One of the interesting questions about authorization is who asks the question. E.g., it doesn't do much good to have a user session ask whether or not it is authorized to do something unless the path to the controlled resource is also working with the same authorization. E.g., take the question of whether the user is authorized to update the Customer table. If the session has a database connection, it is pretty hard to keep it from updating the Customer table, no matter what the service says unless the user is confidently trapped in an application which is going to conform to this limitation. Ideally, no one could access the Customer table directly so that one would have to go through the mediation of a Customer data access object to do anything to the Customer table. But, there is also a question of overhead since, if this data access object is stateless, then it needs to keep banging away on the authorization service for every record.
Initial content adapted from an exchange on the PEG
Bruce Gruenbaum:
The Caching Service is responsible for storing data that may be referred to at a future point in time by this physical session and thereby reduce processing time. Caching with OpenEdge is simply a store of data. In muti-threaded environments, the cache can be self cleaning based on a LRU algorithm or something similar.
Thomas Mercer-Hursh:
I wonder if caching is a service or a property of data access. E.g., take a cache of state and province codes. Does one need to do anything more than create a set object containing that data and remember to not throw it away so that it can be re-used. Or, are you thinking that the way one "remembers" to reuse it is to keep it is something like a temp-table of Pro.Lang.Objects with tags so that they can be provided to any requester. And, of course, one has caches which are complete sets and caches which are simply most recently used, with or without a limit. Not to mention the problem of how to know when the cache is stale.
Initial content adapted from an exchange on PEG.
Bruce Gruenbaum:
The Connection Factory establishes and maintains connections to external targets - databases, AppServers and other TCP/IP targets. It really is responsible for all connectivity to anything that is not in the same process. It handles connection pooling and connection failure. It also abstracts connections into logical connections so that the physical service being requested can be treated separately from the logical connection. This means that a single database connection could be used for multiple logical databases and the same is true for AppServers and any other target.
Thomas Mercer-Hursh
It seems to me that there are a couple of issues here. One of them relates to your environment service, e.g., the environment tells me that I should be able to connect to the billing database so the connection factory can be expected to make that connection as long as the security service agrees that I am personally authorized.
Another relates to the question of local versus centralized sources of information. E.g., if asked to make a connection to a billing database, where does the information come from about where that database resides and what parameters are needed to connect to it?
I am also curious about the technical aspect of the database connection since ABL doesn't have the sort of connection object which is is some 3GLs. With a connection object, one instantiates it and makes it available to whatever needs it and one passes in SQL queries for it to process and has a generic method for handling a result set. Possibly we have the tools to do this in ABL now ... or possibly not ... but is it really something we would want to do? And, if not, then how is the connection made available to the session unless it is established in a top level procedure and then everything is run below that? Also, in the absence of a connection object, how does on centralize things like knowing that a connection has been lost and possibly re-establishing itself?
Initial content adapted from a thread on the PEG
Bruce Gruenbaum:
The Context Management Service is designed to keep track of data that is needed to reestablish a logical session's context on subsequent interactions with a target. People will argue whether context should be stored on the client or the server or both. In my experience, a framework has to provide support for all three options - client, server and both. If one views a set of interactions with a set of targets as a set conversations, context management is about determining where you last left off in the conversation with a specific target.
Thomas Mercer-Hursh:
Or, in the case of AppServer agents, being able to continue the conversation even though you weren't the one who had the last exchange.
Bruce Gruenbaum:
Session management is about reducing the amount of time it takes to determine which target you are talking to.
Thomas Mercer-Hursh:
Agree that one needs all three. One of the interesting twists is supporting a uniform context management solution across multiple client types.
Initial content adapted from an Exchange on the PEG
Bruce Gruenbaum:
The Environment Service determines the context in which the framework is being run. This presupposes that the framework will run in many configurations. Although I am going to talk about it in the context of an OpenEdge application, this is a service that I have written for OpenEdge, Java and C#.
Thomas Mercer-Hursh:
So, from your description, I take it that this service is one per session? Does it have any inputs? Is its output something like an XML document containing a list of cans and can't or does it simply have a bunch of methods of the form "canIDoSuchAndSuch()? Do you see this as a persistent component in each session which is queried repeatedly by the application to determine whether or not it can do something or is it a startup function that passes the information on to the application and goes away? Where does it get its information? E.g., if it is running for a client session with no DB connection, is it going to connect to a DB in order to get the information? Or, do we have a local service and a provider service which is a central source for the information?
Initial content adapted from an exchange on the PEG
Bruce Gruenbaum:
Let me start out by saying that this is service that hitherto has not worked as well for me in OpenEdge as it does in Java/.NET. In a nutshell, it is a service that is responsible for receiving exceptions that have been caught somewhere. The Exception Handling Service receives the exception, logs it to an exception log and then looks for a class that has been designed to process the exception in some way. The trick is to have a standard way of processing all exceptions so that the user never experiences a Java/C#/OpenEdge exception/error condition that has not been handled.
Thomas Mercer-Hursh:
We could use a little more help from PSC on this score, but we are certainly closer than we were to making it possible. To be sure, it is a difficult area to design well, especially since we haven't been given the ability to provide multiple exceptions on a single throw. I have been thinking that I should do a new instance of my exception and condition handling classes in the context of the 10.1C exception handling to help support richer use.
Initial content adapted from an exchange on PEG
Bruce Gruenbaum:
The Logging Service logs every event that takes place in the system that is set to be logged. On a Windows platform these logs are optionally written to the Event Log. Where such services exist on other platforms they are used as appropriate. Exceptions are automatically logged with their complete stack traces.
Thomas Mercer-Hursh
"set to be logged" seems to imply getting configuration data on what to log.
I suppose that it should be a choice, but I can't say that I am personally fond of dumping this sort of information into a generic OS log ... it should be someplace where it is more conspicuous.
This should also include an option for centralized logging. E.g., whenever an unhandled exception occurs, I want that to show up in a central location.
Initial content adapted from an exchange on PEG.
Bruce Gruenbaum:
Session Management and Context Management are closely related but subtly different. A client may have many connections to several different targets. Each of those connections may be termed a session and its lifetime is the duration of the connection. That is a physical session. Many times though, the client makes repeated connections to a target and often to more than one target at a time. It may often be possible to reduce the amount of processing time involved by reusing an authentication token. Thus a logical session may span many connections to many different targets. The Session Manager is responsible of tracking data that is related to the logical session.
Thomas Mercer-Hursh
My own inclination would be to think of a session as the duration of an AVM instance, regardless of what happened to connections since one could have all sorts of interesting complexities like:
1. connect to A
2. connect to B
3. disconnect from A
4. disconnect from B
Perhaps one also wants to have a session-connection instance, one per.
And, for a client, if they are connecting to a state free AppServer, there will be many many connections during one session.
Initial content adapted from an exchange on PEG.