TOC 
D. New
 Invisible Worlds, Inc.
 March 18, 2001

APEX Client Servers
 TOC 

Table of Contents
 TOC 

1. Helpful Reading

APEX I-Ds:

BEEP I-Ds:


 TOC 

2. The Story So Far...

APEX is a generic transport service for applications.

APEX currently supports two classes of applications:


 TOC 

3. One More Time...

APEX is missing support for servers

    (Client/Server type servers)

(Applications unrelated to maintaining APEX, ...

... not related to a particular user, ...

... that use APEX for data transport.)


 TOC 

4. Like What?

File sharing

Bug / FAQ DBs

CPU Sharing

Multi-User Games

Network Monitoring

Intelligent Agent Support (Auctions, etc)

Customer Service Message Routing

Conference Call Support


 TOC 

5. How To Support Such

A brand new structure could be designed, or

... current structures could be adapted.

I propose the latter!


 TOC 

6. Naming Is A Problem

Finding Fred is easy

     Presence for fred@example.com gives endpoint

Finding Presence Service is easy

     Service name *is* Endpoint

No standard way of getting server names

     What presence record?


 TOC 

7. Naming Solution

Presence record for "apex=server@..." lists all server endpoints

Acts like apex=server@... is the "user" for all servers

All administration etc is business as usual


 TOC 

8. Presence Example

A FAQ server and a BUG track database, both from YaddaCorp

FAQ server run by sysadmins, BugDB accessed via "support@example.com"

After "/appl=" comes the name of the server 

<presence
      publisher='apex=server@example.com'
      lastUpdate='....'>
  <tuple
     destination=
       'apex=server/appl=FAQs@example.com'
     availableUntil='...'
     tupleInfo=
       'http://yadda.com/apex/FAQserve'/>
  <tuple
     destination=
       'support/appl=BUGDB@example.com'
     availableUntil='...'
     tupleInfo=
       'http://yadda.com/apex/BUGserve'/>
</presence>

 TOC 

9. What About Access Control?

Right now, access control only for global APEX services

Flat naming scheme makes this difficult to generalize

     Both Sales and Customer Support want to run message routers

Given strict naming control from Presence, 'service' could include 'server'

     Central point of control

Portion after "/appl=" becomes service name for action attribute


 TOC 

10. Access Example

Only example.com allowed to see bugs or change FAQs

All users allowed to see FAQs 

<access owner='apex=server@example.com'
        lastUpdate='...'
  <entry actor='root@example.com' actions='all:all'/>
  <entry actor='*@example.com' 
    actions='BUGDB:all FAQs:read FAQs:write'/>
  <entry actor='*@*' 
    actions='BUGDB:none FAQs:read'/>
</access>

 TOC 

11. Client Code Responsibilities

Client code would need to fetch and parse presence records

     (To find right endpoint given tupleInfo URI)

Server code would need to fetch and parse access records

     (Subscribe would be nice here)

Otherwise, business as usual


 TOC 

12. Open Questions

Is there a better name for such servers?

Is there a better approach?

Is an endpoint not under apex=server reasonable?

    (E.g., "support/appl=BugDB@...")

If so, where is the access record?

     (Under "apex=server@..." or "support@..."?)