ACS Documentation : Systems Integrator's Guide to the ACS : CORBA and EJB Interfaces to the ACS
<More introductory information here, e.g., the distinction between ACS acting as a CORBA/EJB server and ACS acting as a CORBA/EJB client>
If you could not find the user, then you'll want to create him:// First try his e-mail address. UserRecord acs_user = acs_user_home.get_user_by_email( "mayoff@arsdigita.com"); 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); }
Later on, when you want to come back to the user, you can access him by ACS user id:if (acs_user == null) { acs_user = new UserRecord(); acs_user.first_names = "Rob"; acs_user.last_name = "Mayoff"; acs_user.email = "mayoff@arsdigita.com"; 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);
...
...
Interfaces:
com.arsdigita.CORBA.ACS
. The Java interfaces for the
ACS/EJB interface are in com.arsdigita.EJB.ACS
.
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.
Concretely, here's what you'd like:
/acs
object in the
registered object directory.
ad = acs.get_most_recent_ad(some_user_id)
and gets back a reference to a ClassifiedAd.
sor = orb.object_to_string(ad)
, and writes
this stringified object reference to a file.
ad = orb.string_to_object(sor)
on it.
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:
/acs
object in the
registered object directory.
ad = acs.get_most_recent_ad(some_user_id)
and gets back a reference to a ClassifiedAd.
id = ad.get_id()
, and writes
this stringified object reference to a file.
/acs
object in the
registered object directory.
ad = acs.get_ad_by_id(id)
,
and gets back a reference to a ClassifiedAd.
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.
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.
java.util.Date
, which
is serializable.) There are basically three possibilities: