After our EPSFW workshop I have some notes on some of the work
that might be done between now and San Diego. We wish to
expand the specifications associated with our model and enhance the
requirements to evolve the EPSFW draft. The details will be in
clarification
of how things could work, needed protocols, APIs, etc. all of which will
define pieces that eventually evolve the overall architecture.
I will be posting the slides and notes later.
Let me try and spell out some things to do, and I would like some
volenteers
and additions. Please make suggestions!!!
1. Services/Proxylet requirements:
Here a particular service is examined in detail, with a
use case or implementation or both. Results will exhibit the
specifications either at the detailed level (APIs and protocols)
or at the requirements level.
Alex Shah gave us a detailed Use Case for his
MyWebBook. Markus Hoffman and Katy Guo gave us some
implementations that could be mapped into the
framework. Senthil Kumar <Vs(_dot_)Senthilkumar(_at_)india(_dot_)sun(_dot_)com>
and I tried to
enhance the "University Accounting" USE-CASE.
Things we need to do (as much as possible)
a. Explain what needs to be done including examples of required
protocols, functions, rule expectations and library
expectations.
b. Propose a design that is consistent with the requirements in EPSFW.
Suggest requirement changes if necessary.
c. Implement code for the service or show how thing need to work
with a detailed Use Case.
d. Describe enhancements or details to the EPSFW framework.
Senthil Kumar <Vs(_dot_)Senthilkumar(_at_)india(_dot_)sun(_dot_)com> and I
tried to
enhance the "University Accounting" USE-CASE. Kumar's
group may be able to implement this by San Diego. This is
quite simple and no example protocols or APIs are shown
thus far.
Example Service Projects that I can think of:
* Steaming Media with Caching changes
* Content Assembly - improving Yahoo
a. Ad insertion
b. Tickertape
c. MyWebBook
d. Localization
* PBX control
* Transcoding
* University Accounting
* ICAP examples
Look the list over, pick one or insert more in the list.
2. Rule Model
Dave Farber started with some rule issues and Markus has sent
out some additional requirements. We need to collect
these requirements and update the draft.
We could also build a small rule engine. Just a simple case could
be used to expand things:
* HTTP/HTML only - certainly not the framework requirements.
* Schema to represent rules
* Simple conflict model
Now we need
* tools to analyze rule specifications
* engine for executing rules and firing proxylets
lots more.
3. Security/Accounting
What is the AAA model for our EPSFW environement.
Understanding the scope of rulets and proxylets
is critical. There is lots to be done here.
I am certainly open to suggestions.
Michael
condry(_at_)condry(_dot_)org
As one example, let us expand the "Univeristy Accounting"
use case. Here the objective was to create a log of the class URLs
used by the students along with some indication of usage time. Using
EPSFW was ideal because the professor designing the accounting for
his classes does not necessary have the right to modify the web
pages used for his class and the Client/User Agent is certainly
not a suitable place to do this.
This is a simple use case but it does call on all the
key components. The key componets are shown in the diagram
below:
+----------------+
| Accounting |
| Callout |
| Server |
+----------------+
A |
| |
| |
| V
+----------------+
| |
+----------+ | PROXY SERVER | +-----------+
|Client |<-------|4 3|<-----------| Content |
|User agent|------->|1 ------------ 2|----------->| Server(s) |
+----------+ | | +-----------+
| proxylets |
| |
+----------------+
A |
| |
| V
+----------------+
| Adminsitraion |
| Server |
+----------------+
PROXYLETS
The proxy server executes the proxylets that we use to do the
accounting. There are three proxylets:
a. The login proxylet that essentially "starts" the proxy based
accounting session. There are several ways we might stimulate
this but we are assuming that the student is required to
login into a "class URL" in order to access the class
web pages. This creates data kept in the proxy server
for accounting; it is the process that identifies the student.
b. The logout proxylet is used to "clear out" the user information
being kept by Proxy Server. This can be executed explicitally
or by a timeout. So an "inactive use" timer is in the system
and when fired can cause this proxylet to execute as well as
going to an explicit logout URL. This "inactive use" timer
is determined by the value set in the "student active time"
set by the log proxylet.
c. The log proxylet creates a log entry when the student accesses
a content server. This data is passed to the accounting
callout server for further processing.
The record looks something like
<Student-ID, Class-URL, Time>
The proxylet would also set a "student active time" variable each time
its fired for this student.
RULES
The rule mechanism is based only the URLs of requests and timer data. There are
some
choices in rules. Three primary mechanisms could be used to elect when a
class URL proxylet should be fired:
i. Fire for all URLs
ii. Fire with URLS matching a regular expression (like "149.146.22.*")
ii. Fire with URLs found in a list
Establishing which is the most suitable set of rules and analying each is a
good project.
For now, lets just assume that all the appropriate URLs will be specificable by
a
simple regular expression.
PROCESS
Now the operation of the system will go as follows. First we have an
administration
set up procedure:
1) Verify correctness and security of the rules and proxylets.
2) Administrator installs the proxylets and rules to
the proxy. This would install the
i) login proxylet
ii) logout proxylet
iii) log proxylet(s)
It would also install the rulets (URLs) that specify the login and
logout
URLs and the regular expression that describes the class web page URLs.
Now, once installed the system can be used:
0) User (the student) sets his browser proxy to point
to the main PROXY required to be use for classwork. This will direct
the students agent to go through our example proxy server.
1) Now student's "login" to the class system by going to the class login
webpage.
Student submitting the login web page triggers login proxylet. Since
Login
proxylet knows about login form, it picks up student info from it.
It sets up internal
information to associate activity from this client to be identified
as this student.
2) After the login, the student accesses the class URLs through their
browser. The rule
system matches this URL and fires the log proxylet.
The proxylet looks up the student id (knowing the ip connection of
the client) then logs the class
access record which looks like:
<Student-ID, Class-URL, Access Time>
This is passed on ot the Accounting Callout Server. An XML format
for the data would
be likely. Callout server logs all these info. This proxylet also
sets the
"student active" timer to indicate that a page was accessed at this
time.
3) At some point the student will quit accessing pages. A "logout" URL
will be provided.
If the student accesses the logout URL or if too much time passes and
the timer fires
because the student is not active, this will trigger the logout
proxylet.
The logout proxylet removes the student information from the within
the proxy. This should
also remove access to the class web pages until a "login" procedure
is executed again.
External to this process, the professor takes the data logs on the callout
accounting processor and
does whatever analysis desired on the data. This could re-set the logs. The
professor must also
set up the login/logout URLs.