CORBA and EJB Interfaces to the ACS

ACS Documentation : Systems Integrator's Guide to the ACS : CORBA and EJB Interfaces to the ACS

ACS4: Work In Progress

Introduction: Why Remote Procedure Call Interfaces?

<More introductory information here, e.g., the distinction between ACS acting as a CORBA/EJB server and ACS acting as a CORBA/EJB client>

Client Scenarios

Scenario: ACS User Management

// First try his e-mail address.
UserRecord acs_user = acs_user_home.get_user_by_email(
    "");

if (acs_user == null) {
    // Not found; try his name.
    acs_user = acs_user_home.get_user_by_name("Rob",
        "Mayoff");
}

if (acs_user != null) {
    // Found him.
    System.out.println("Rob Mayoff has user_id "
        + acs_user.user_id);
}

if (acs_user == null) {
    acs_user = new UserRecord();
    acs_user.first_names = "Rob";
    acs_user.last_name = "Mayoff";
    acs_user.email = "";
    acs_user.password = "dqd";
    acs_user = acs_user_home.create_user(acs_user);
    System.out.println("Rob Mayoff has user_id "
        + acs_user.user_id);
}

UserRecord acs_user = acs_user_home.get_user_by_id(123);

Scenario: Ticket Summary

...

Scenario: Authorization

...

Notes from 2000-6-5 Conference

• Higher-level: what does the interface let you do?
• Discuss performance: describe how to use our system, and how to move to a higher-performance configuration

  Interfaces:

• register a new user, get user_id back
• submit ticket:
• what projects are available in the ticket tracker, and what subprojects?

• search for user by last name, e-mail address, etc.
• look for ad_permission_p type functions in PL/SQL
• describe scenarios: e.g. web application talking to a remote ACS

• Divide into different IDL modules for different parts of ACS
• See about getting package manager to automatically install EJB/CORBA interfaces

Package Names

We can't just use com.arsdigita.ACS for both, because we might reasonably want a User class in each interface, but the class must be defined differently under the two frameworks.

Object References

Concretely, here's what you'd like:

• The client looks up the /acs object in the registered object directory.
• The client calls ad = acs.get_most_recent_ad(some_user_id) and gets back a reference to a ClassifiedAd.
• The client calls sor = orb.object_to_string(ad), and writes this stringified object reference to a file.
• The client exits.
• Time passes.
• The client runs again.
• The client reads the object reference from the file and calls ad = orb.string_to_object(sor) on it.
• The client calls one_line = ad.get_one_line() to get the one-line description of the ad. If the in-memory object no longer exists, the server recreates it from the database.

There are CORBA implementations that allow this sort of behavior, by encoding the object's type and primary key in the object reference. Alas, Oracle's isn't one of them. When the client exits after its first run, all the remote objects it had accessed are destroyed. When you get to the last step, and Oracle is your server, you get an OBJECT_NOT_EXIST exception. Oracle's ORB is too primitive to recreate objects from object references.

Instead, the client must do this:

• The client looks up the /acs object in the registered object directory.
• The client calls ad = acs.get_most_recent_ad(some_user_id) and gets back a reference to a ClassifiedAd.
• The client calls id = ad.get_id(), and writes this stringified object reference to a file.
• The client exits.
• Time passes.
• The client runs again.
• The client looks up the /acs object in the registered object directory.
• The client reads the classified ad id from disk, calls calls ad = acs.get_ad_by_id(id), and gets back a reference to a ClassifiedAd.
• The client calls one_line = ad.get_one_line() to get the one-line description of the ad.

Admittedly, the sequence doesn't look all that different. But now the client can't just use the object reference directly in its second run. It must look up the factory object in the namespace when it might otherwise not need to, and it must call get_ad_by_id instead of string_to_object. Both of these are extra round-trips to the server (string_to_object does not require a trip to the server). The client also needs to tell the server how to recreate the object by using a class-specific method, get_ad_by_id.

Similar arguments apply for Oracle's EJB implementation. The EJB specification defines the concept of "entity beans", which would be persistent across runs, etc. But Oracle doesn't implement entity beans as of 8.1.6.

Authentication

Since we don't require each user to have a separate Oracle identity, we can't use the Oracle CORBA security features for authentication and authorization. Instead, after the client has authenticated itself to Oracle using some shared identity, it looks up the ACS login object in the namespace and calls its login method, in an e-mail address and password. The login method raises an exception on authentication failure. On success, it returns a new object that knows the user's identity and provides methods for accessing the ACS.

Dates

1. Pass dates as strings in 'YYYY-MM-DD HH24:MI:SS' format.
2. Pass dates in a structure containing separate fields for year, month, day, etc. This basically means parsing the format from #1 on the server side instead of the client side.
3. Pass dates as seconds since the UNIX epoch. This style sends the least data on the wire and has direct support in the Java and C standard libraries.