Method and apparatus for an improved security system mechanism in a business applications management system platform6850893Abstract The present invention provides a solution to the needs described above through an improved method and apparatus for an improved security system mechanism in a business applications management system platform. The security management system partitions a number of business objects into a number of hierarchical domains. A security list is then created and configured to grant a member the right to perform a security operation on the business object located within the hierarchical domain. The security list is created by adding the security operation to the security list, applying the security operation to one of the multiple domains, and adding members to the security list. Claims We claim: Description COPYRIGHT NOTICE
1. fgt_dd_class
Every business object in the system is registered in this table. This table also describes basic properties of objects. fgt_dd_class has the following columns:
Column Name Type Rq? Description
Id Char (20) The identifier of the object.
Ui_name Varchar2 (255) This is the display name of
the object and generally
used to paint UI as well.
Description Varchar2 (255) Meaningful description of
the object and its function.
Enumber int Unique number for each
object.
Insert_spid Int Method call for inserting a
new instance of the object.
Foreign key to mesg_id
column of fgt_mesg_table.
Update_spid Int Method call for updating an
existing instance of the
object. Foreign key to
mesg_id column of
fgt_mesg_table.
Delete_spid Int Method call for deleting an
instance of the object.
Foreign key to mesg_id
column of fgt_mesg_table.
Sel_det_spid Int Method call for retrieving
an instance of the object
based on its id. Foreign key
to mesg_id column of
fgt_mesg_table.
Finder_id Int Finder Id for invoking a
default finder associated
with the object.
Fixed_attr_ct Int Total count of the fixed
attributes for the object.
Attr_ct Int Total count of the attributes
for the object. This number
is sum of all fixed and all
custom attributes.
Flags Char (10) Ten bit string describes the
behavior of the object.
1st bit = Object can be
displayed in the security
screen for granting privs.
2nd bit = This 2bit mask is
set to see if reports or
letters or both can be
attached.
3rd bit = Obsolete.
4th bit = Obsolete.
5th bit = If the object is
owned in nature and cannot
exist without its owner.
6th bit = Obsolete
7th bit = If object can be
customized bu end user.
8th bit = If Object can have
Extensible attributes of its
own.
next_attr_enum Int Enumber to use for the next
custom attribute that will be
added to the object. The
install time value for this
attribute is 10,000.
Prefix char (5) This 5letter long string is
used in generating Ids for
the object. This string is
prepended to the number
generated by the sequence.
Table_name Varchar2 (25) This is the name where the
object is stored. The
sequence, methods are also
named based on this.
Domain_enum Int This is denormalized data
and shows the enumber of
the Domain attribute.
Java_class_name Varchar2 (255) The java class name of the
object.
Hlevel Int The level of the object in
the object hierarchy.
Parent_id Char (20) In case of hierarchical
object's it stores the parent
object's id
As an example, the following are the values for a class of business object representing domains:
id ui_name description enumber insert_spid
ddcls000000 Domain Hierarchal 195 10560
000001095 Domain
update_spid delete_spid sel_det_spid finder_id fixed_attr_ct
10562 10561 10563 15710 14
attr_ct flags next_attr_enu prefix table_name
m
14 1100001100 100000 domin fgt_domain
domain_enum java_class_name hlevel parent_id
com.saba.busobj.Sa 1
baDomain
2. fgt_dd_attr The attributes of each class of business object is stored in this table. This table also describes basic properties of each attribute. fgt_dd_attr has the following columns:
Colunn Name Type Rq? Description
Id Char (20) Y Unique identifier for an
attribute.
Cid OBJECTID Y The object id, this
attribute belongs to
Enumber Int Y Required to be unique within
a class. The code should use
these numbers to refer to
attributes rather than using
the ID. Fixed enumbers are
assigned in the range 1000-
9999. Extensible attributes
are allocated from 10,000
onwards. The next_attr_enum
in the corresponding object
record stores the next
enumber available for this
class.
Col_name Varchar (255) Y The column name in which the
value of this attribute is
stored.
Ui_name Varchar (255) Y The name of the attribute,
which is used for painting
the UI.
description Varchar (255) N Description of the
attribute.
Attr_type Int Y The number corresponds to
the data type of the
attribute.
list_of_vals OBJECTID N If the attribute val. is
selected from a list of
values, then the id of the
list is stored here.
min_val Int N If its a numeric column,
then the min allowable value
if any.
max_val Int N If its a numeric column,
then the max allowable value
if any.
default_val STR N Default value to use for the
attribute when an instance
of the object is created.
str_1 STR N This generation formula for
those attributes whose
values have to be generated
on the creation of the
object. The generation is
driven by the generation bit
in the flag.
Flags varchar (15) Y 1.sup.st bit => The required
bit.
2.sup.nd bit => Reference bit is
set if attribute points to
another object.
3.sup.rd bit => LOV bit is set
if its values must come from
fixed list of values.
4.sup.th bit => This two bit
mask describes the type of
the attribute.
5.sup.th bit => Id bit is set if
its an Id column.
6.sup.th bit => Generation bit
is set if the value need to
be generated during the
creation of an object.
7.sup.th bit => Customization
bit. This 4bit mask says if
label, required or
generation can be customized
by end user.
8.sup.th bit => Audit bit.
9.sup.th bit => Obsolete
10.sup.th bit => Obsolete
11.sup.th bit => This bit
describes the type of the
custom attribute.
12.sup.th bit => Domain bit is set
if the attribute is domain
id.
13.sup.th bit => set if Default
value can be changed by
user.
14.sup.th bit => set if Minimum
value can be changed by
user.
15.sup.th bit => set if Maximum
value can be changed by
user.
As an example, the following are some of the attributes defined for the domain business object:
id cid enumber col_name ui_name attr_type
flags
ddatr000 ddcls0 1000 id ID 8
100011000
0000000 00000
000000
02991 00000
1095
ddatr000 ddcls0 1001 time.sub.-- Time 4
100000000
0000000 00000 stamp Stamp
000000
02992 00000
1095
ddatr000 ddcls0 1002 name Domain 4
100000100
0000000 00000 Name
000100
02993 00000
1095
ddatr000 ddcls0 1003 description Description 7
000000300
0000000 00000
000100
02994 00000
1095
ddatr000 ddcls0 1004 custom0 custom0 7
000100300
0000000 00000
010100
02995 00000
1095
3. fgt_mesg_table This table stores the actual SQL code used for object persistence. In the case of insert, update, and delete methods, typically these are calls to stored procedures containing additional business logic in addition to database calls. Long SQL statements are stored in multiple rows, which are then reconstructed on-the-fly by the persistence layer. fgt_mesg_table has the following columns:
Column Name Type Rq? Description
Mesg_id Int Y This is the message id for
the SQL statement group.
Mesg_seq Int Y Since the SQL statements can
be greater than 255 chars
which is the length of the
mesg_text columns. This
column tells the sequence of
this SQL statement in the
group.
Mesg_text Varchar (255) Y The text of message.
As an example, the following are persistence calls for the domain business object. Note from the sample data above that 10563 is the code for retrieving an object, 10560 for inserting an object, and 10562 for updating an object.
mesg_id mesg_seq mesg_text
10563 1 select d.id id, d.time_stamp ts, d.name
dname, d.description descr, d.custom0 c0,
d.custom1 c1, d.custom2 c2, d.custom3 c3,
d.custom4 c4, d.created_on cron, d.created_by
crby, d.updated_on upon, d.upd
10563 2 ated_by upby, d.parent_id pid, parent.name
parent from fgt_domain d, fgt_domain parent
where d.id = @001 and d.parent_id =
parent.id(+)
10560 1 begin fgp_domain_ins (@001, @002, @003,
@004, @005, @006, @007, @008, @009,
@010, @011, @012, @013, @014, @015); end;
10562 1 begin fgp_domain_upd (@001, @002, @003,
@004, @005, @006, @007, @008, @009,
@010, @011, @012, @013, @014, @015); end;
Notice that the SQL references the actual table used to store domain data, fgt_domain (described in detail in the section on security).
The fgp_domain_ins stored procedure is PL/SQL code defined as:
create or replace procedure fgp_domain_ins
(
xid char,
xtime_stamp varchar2,
xname varchar2,
xdescription varchar2,
xcustom0 varchar2,
xcustom1 varchar2,
xcustom2 varchar2,
xcustom3 varchar2,
xcustom4 varchar2,
xcreated_on date,
xcreated_by varchar2,
xupdated_on date,
xupdated_by varchar2,
xparent_id char,
xnewts varchar2
)
as
begin
/* validating that the parent of a node is not
itself */
if (xid = xparent_id) then
raise_application_error(-20698, ' ');
return;
end if;
/* parent_id cannot be null except for the root */
if (xid <> 'domin000000000000001' and xparent_id is
null) then
raise_application_error(-20699, ' ');
return;
end if;
insert into fgt_domain (
id, time_stamp, name, ci_name, description,
custom0, custom1,
custom2, custom3, custom4, created_on,
created_by, updated_on,
updated_by, parent_id)
values (
xid, xnewts, xname, lower(xname),
xdescription, xcustom0, xcustom1,
xcustom2, xcustom3, xcustom4, sysdate,
xcreated_by, sysdate,
xupdated_by, xparent_id);
/* update the denormalized flat tree table */
tpp_flat_tree_relation(195, xid, null, null, 0);
/* inherit a snapshot of the custom fields for all
objects */
insert into fgt_dd_domain_to_attr
(ID, TIME_STAMP, DOMAIN_ID, ATTR_ID,
FLAGS, LOCAL_FLAGS, UI_NAME, MIN_VAL,
MAX_VAL, DEFAULT_VAL, LIST_OF_VALS,
GEN_MASK)
select `ddoat` .vertline. .vertline.
lpad(ltrim(rtrim(to_char(fgt_dd_domain_to_attr_seq.nextval))), 15,
`0`),
xnewts, xid, ATTR_ID, FLAGS, LOCAL_FLAGS,
UI_NAME, MIN_VAL,
MAX_VAL, DEFAULT_VAL,
LIST_OF_VALS, GEN_MASK
from fgt_dd_domain_to_attr
where domain_id = xparent_id;
end;
2b. Persistence Algorithms In a preferred embodiment all business objects that Saba's Application server manipulates are derived from a single base class called SabaObject. The SabaObject class provides save, restore, and delete capabilities by implementing the persistence layer architecture. All subclasses of SabaObject then inherit this behavior and rarely if ever override it. Every SabaObject is expected to know which class it belongs to, and how that class is registered in the meta-data store. Thus each subclass of SabaObject stores a class identifier so that it can tell the system which entry in the meta-data store it corresponds to. Every SabaObject also stores a state flag that determines whether this is a new object, or it is an object that already exists in the data store. This state then determines whether the object invokes an insert method or an update method during a save( ) invocation. Every SabaObject has an unchangeable, unique identifier that identifies that particular object in the persistence store. The uniqueness of this identifier is guaranteed across the entire persistence store regardless of the type of object. The algorithm for save is then as follows: Look up the entry for the class of the object in the meta-data store. If the class is not found, raise an error "Unknown Class". If (State=new) M=look up the method to call for inserting the object. Else/*State=update*/ M=look up the method to call for updating the object Marshall all the attributes of the SabaObject into the appropriate data structure. Check each of the attributes against the rules set for its nullity, constraints. If any of the constraints are violated, throw an error. Lead the default values wherever necessary. Invoke M with that data structure. (1) For deletion, the basic process is identical, except that the invocation of the delete method only requires the unique identifier of the SabaObject to be passed in as its only argument. For restore, the algorithm is just slightly different and is as follows: Look up the entry for the class of the object in the meta-data store. If the class is not found, raise an error "Unknown Class". M=look up the method to call for fetching the object. Invoke M(unique ID of SabaObject) Unmarshall all the attributes returned by M. (2) In the presently preferred embodiment, the method invocation currently only supports invocation of database stored procedures although in alternative embodiments this will be extended to other types of persistence mechanisms. These stored procedures provide the actual intelligence of taking the marshaled arguments that come in, and storing them in specific fields in the database, and vice versa. Thus a combination of the meta-data store and the stored procedures create an abstraction layer that allows the base SabaObject to store all objects through a simple, uniform algorithm. ##STR1## The persistence mechanism thus created allows the transfer of various kinds of objects to database storage as shown below. ##STR2## Individual messages are retrieved using a SQL command of the form:
select mesg_id, mesg_seq, mesg_text from fgt_mesg_table
where mesg_id = ? order by mesg_id, mesg_seq
Query results are transformed into actual SQL code using the following method:
private static String processMessage(ResultSet rSet)
throws Exception, SabaException
{
StringBuffer buf;
String str;
buf = new StringBuffer(rSet.getString(kMsgTextCol));
while (rSet.next( ) != false)
{
String temp = rSet.getString(kMsgTextCol);
buf.append(temp);
}
str = buf.toString( );
return str;
}
}
Retrieved messages are also stored in a local cache for improved performance. 2c. Configurable Custom Fields In the preferred embodiment, the Saba persistence mechanism provides built-in support for configurable, runtime definable, custom fields for any object. The basic mechanism is extremely simple. An administrative user interface is provided by which the meta-data definition of a given class can be extended by adding (or removing) custom attributes as needed. For each custom attribute, the user only needs to provide some very basic information about the type of the field, whether or not it is required, constraining minimum and maximum values for numeric fields, and a constraining list if the field is to be validated against a list of possible values. The SabaObject implementation then simply picks up these fields during its normal marshalling and unmarshalling of arguments. Further, the SabaObject also performs the basic checks for nullity as it would normally do. To save and restore the custom fields, the actual algorithms are extended from the ones shown earlier. In the case of insert or update the following additional lines are called after the line marked (1) in the algorithm shown earlier: After invoking the basic method M Marshall all custom field data into the appropriate data structure Invoke the insert/update method for storing the custom data structure. In the case of restore, the following lines are added to the original algorithm after the line marked (2): Invoke the custom field fetch Unmarshall all custom field data and update the relevant fields in the SabaObject. The actual storage where the custom field data for any given instance is stored, consists of a single table as defined below. All the custom field data is stored as tag-value pairs in typed columns. Fgt_dd_custom This common table provides the storage area for all data stored in the extended custom fields for a given object.
Column Name Type Rq? Description
Id OBJECTID Y
owner_id OBJECTID Y Which object this custom
field is for.
attr_id OBJECTID Y Refer to the attribute
for which value is
stored.
attr_type INT Y Type of the custom field.
This matches the attr_type in
the fgt_dd_attr table and is
a denormalization of the
same.
Num_value Number N Value is stored here if it is
Numeric type
Str_value Varchar (255) N Value is stored here if
it is String type
Date_value Date N Value is stored here if it is
Date type
3 Core Services BDK also provides a set of core services to perform useful operations on business objects. Some of these services include: Security. BDK provides extremely fine-grained security control to control whether specific users have privileges to perform operations such as creating or viewing a particular class of business object. The system is unique in that it provides a flexible model of security roles and security lists to assign a set of privileges to distinct groups of users, and it employs a scalable notion of domains to differentiate among sets of business objects. The security model is explained in detail in a separate section below. Auditing. BDK provides the ability to track the history of all changes to an object, including the date of a change, the identity of the user making the change, and a justification for the change. Internationalization (i18n). BDK provides utilities for allowing business objects to be internationalized. Internationalization is a standardized process wherein message content, money amounts, dates and various other culture specific data are kept in separate files in order to permit an easy change from one countries language and cultural rules to another. This comprises both storing values of business objects in multiple languages and supporting multiple formats for date, currency, and other data types that vary among countries. Concurrency. BDK provides concurrency services for controlling overlapping write operations on multiple instances of an object, while permitting multiple reads at the same time. This is achieved via comparison of an instance-specific timestamp when committing of an object's state to the persistent store is requested. The timestamp is updated whenever the state of an object is altered and the object is successfully committed to persistent storage. Transaction Management. BDK provides two types of transactional services: procedural and declarative. In the former case, a developer explicitly marks the beginning and end of a unit-of-work using BDK's API. In the latter case, a developer can associate a transactional attribute with a method, and the BDK's Transaction Monitor keeps track of initiating and terminating transactions, as well as executing a method within the scope of an on-going transaction, based on run-time context. Logging. BDK provides logging functionality that can be used for capturing system state and operations in one or more logs. Notification. BDK provides the ability to send notifications, such as emails or faxes, to predefined categories of users when the state of identified business objects changes. For example, everyone subscribed to a class may receive a page if the class is cancelled. Business Rules. In a preferred embodiment, for example, Saba's learning application provides a set of pre-defined business rules that affect the workflow and behavior of various business objects in the system. The BDK provides a mechanism to enable and disable these business rules. For example, a customer can configure whether a manager's approval is required to register for a class. Similar business rules can be handled for other types of applications. Notes. BDK provides the ability to associate arbitrary, free-form text, or "notes," with any business object in the system. 4 Application Programming Interfaces In the preferred embodiment, the BDK exposes Application Programming Interfaces (APIs) for use in programming the system. A variety of APIs with equivalent functionality are supported on top of the persistence framework. The system supports both propriety and industry-standard forms of Java API, as well as XML-based APIs. a. SabaObject API One Java API is a proprietary "SabaObject" interface to a business object. A SabaObject is a Java class defining a set of operations common to all business objects, including the ability to get and set properties using a variety of data types and the ability to save and restore an object's state. Specific business object classes can subclass SabaObject to add functionality and business logic appropriate to that class. The Java interface for SabaObject is the following:
public class SabaObject {
/**
* SabaObject Constructor
* Creates a new empty Saba object in the context of the
given session.
*/
public SabaObject(String sessionKey);
/* methods to set attribute values as different datatypes
*/
public void setAttrVal(String attrName, Boolean attrVal);
public void setAttrVal(String attrName, Timestamp
attrVal);
public void setAttrVal(String attrName, Integer attrVal);
public void setAttrVal(String attrName, BigDecimal
attrVal);
public void setAttrVal(String attrName, String attrVal);
public void setAttrVal(String attrName, Object attrVal);
/* methods to restore attribute values as different
datatypes */
public String getAttrVal(String attrName);
public String getStringAttrVal(String attrName);
public Integer getIntegerAttrVal(String attrName);
public Timestamp getTimestampAttrVal(String attrName);
public BigDecimal getBigDecimalAttrVal(String attrName);
public Boolean getBooleanAttrVal(String attrName);
/**
* Gets a hashtable of the attribute values.
*/
public Hashtable getAttributeValues( );
/**
* Returns the display label for the named attribute
*/
public String getAttributeLabel(String attrName);
/* save, restore, and delete methods */
public void save( );
public void save(SabaTransaction tr);
public void restore( );
public void restore(SabaTransaction tr);
public void delete( );
}
In the preferred embodiment, as part of a business object's creation, the business object author provides four SQL statements corresponding to selection, deletion, insertion, and updating of the object. Pointers to these statements are provided as part of the metadata for the object as stored in fgt_dd_class. The first two (selection and deletion) types of statements take a single bind variable, namely, the id of the object. The other two take the id as well as all other attribute values in the order declared in the metadata for that object's attributes in the table fgt_dd_attr. The order of retrieval of attributes in the selection statement must also match such order. Upon receiving a request to create an in-memory representation of an object through the "restore( )" method, BDK retrieves the selection statement for that class of objects, binds the variable to the id of the object that is desired to be restored, executes the statement, and fills in an instance-specific hashtable of attribute-value pairs with the values so retrieved. In addition, a standard SQL statement is executed to retrieve the value of extended custom attributes, and the results are again inserted in the aforementioned hashtable. For the "restore(SabaTransaction tr)" variant of this operation, the execution of these SQL statements is done using the database connection contained in tr, the transaction argument. When executing the "delete( )" method, the object is marked for deletion. Upon a subsequent call to "save( )" or "save(SabaTransaction tr)," BDK checks for the state of the object. If it is an object that has been marked for deletion, the deletion SQL statement as supplied by the business object author is executed after binding the id, using the database connection in the transaction argument for the "save(SabaTransaction tr)" case. Other possibilities upon execution of the save operation are that the object instance is new, or it is an altered state of an existing object. In these cases, the statements corresponding to insertion and updating are executed, respectively, after the replacing the bind variables with attribute values from the hashtable in the order specified in metadata. In the case of insertion, BDK automatically generates a unique id for the object that is reflected both in the persistent storage and the in-memory representation. Implementation of the setAttrVal( ) and get<type>AttrVal( ) involve setting and accessing values in the hashtable, respectively, using the provided attribute name as the key. getAttributeValues( ) returns a copy of the object's hashtable whereas getAttributeLabel( ) looks up the attributes' metadata and returns the label corresponding to the chosen attribute. 4b. SabaEntityBean API Another Java API is based on the industry-standard Enterprise JavaBean (EJB) model. This model has a notion of "entity beans" that provide the interface to specific business objects. Accordingly, the persistence framework provides a EJB-based abstract class, "SabaEntityBean" that implements the javax.ejb.EntityBean interface. The SabaEntityBean class provides default implementations of the following methods: ejbActivate( ), ejbPassivate( ), ejbRemove( ), setEntityContext( ), ejbCreate( ), ejbLoad( ), ejbStore( ), and unsetEntityContext( ). Implementations of the ejbLoad( ), ejbStore( ), ejbCreate, and ejbRemove( ) methods rely on the selection, update, insertion, and deletion statements declared as part of metadata (please refer to the discussion of the implementation of SabaObject's API). Other methods are implemented as empty stubs that can be overridden by a developer if desired. In addition to defining the bean class, to implement an EJB one also needs to define a corresponding remote interface, a home interface, and, for entity beans, a primary key class. The remote interface is the external world's view of the bean and is comprised of the business methods that the bean wishes to expose. The getters and setters for the bean's attributes are also exposed through the remote interface. The home interface declares the life-cycle methods, such as those for creating, removing, or finding beans. In the preferred embodiment, the BDK provides two interfaces, ISabaRemote and ISabaHome, which a bean can extend for defining remote and home interfaces, respectively. The ISabaRemote interface extends the standard EJB interface EJBObject and provides the following sets of methods: void setCustomAttrVal(String attr, <type> value), and <type> getCustomAttrVal(String attr) for Boolean, Timestamp, String, Integer, Float, and Double data types. The ISabaHome interface provides a layer of abstraction over the standard EJB interface EJBHome. The BDK also defines a class SabaPrimaryKey (a thin wrapper around the String class) which can be used by entity beans for defining primary keys. 4c. Session Manager APIs The EJB model also has a notion of "session beans," higher-level interfaces that represent business processes. In the preferred embodiment, the BDK has standardized on the use of session bean-based interfaces as its public API; these interfaces are known as "session bean managers," and are implemented using the lower-level entity bean APIs provided by the persistence layer. The BDK provides a SabaSessionBean base class that defines common session bean manager functionality, and a framework for several categories of "helper classes"--additional interfaces used in conjunction with specific session bean managers: Detail--represent immutable detail information about a specific business object Handle--represent opaque references to a business object Primitive--represent commonly used data structures, such as addresses and full names 4d. XML Interfaces In the preferred embodiment, the BDK also provides XML-based interfaces for saving and retrieving business objects; these interfaces provide the communication layer with the other Platform servers and components. One XML format is known as "Saba Canonical Format" (SCF). It is an XML serialization of the data in a SabaObject. The Interconnect server system reads and writes SCF to implement the AccessorReader and ImporterWriter for the native Saba system; refer to the Interconnect server section for more details. An example fragment of an SCF document, representing a business object defining a specific currency, is:
<SabaObject type="com.saba.busobj.SabaCurrency"
id="crncy000000000000001" status="existing">
<name dt:type="string">US Dollars</name>
<time_stamp
dt:type="string">199812161647032900</time_stamp>
<short_name dt:type="string" >USD</short_name>
<flags dt:type="string">1100000000</flags>
</SabaObject>
In the preferred embodiment, another XML interface is the "IXMLObject" interface. An IXMLObject is a Java object capable of serializing itself into an XML representation. The detail, handle, and primitive helper objects used by session bean managers all implement this interface. The WDK server system uses these objects to generate dynamic web content by invoking the session bean manager APIs, then serializing the resulting objects into XML; refer to the WDK section for more details. The IXMLObject interface conforms to the "Visitor" design pattern, and is defined as follows:
public interface IXMLObject {
/**
* Accept a visitor. An implementation should ask the
Visitor to visit each of its public elements (i.e., fields or
properties).
*
* @param visitor The XML Visitor object
*/
public void acceptXMLVisitor(IXMLVisitor visitor) throws
XMLVisitorException;
/**
* Get the preferred tag name for this object.
* @return the tag name to identify
*/
public String getTagName( );
}
Note: a "visitor" object is one which has processes which represent an operation to be performed on the elements of an object structure. A visitor lets one define a new operation without changing the classes of the elements on which it operates. Visitor objects and their operation and use are described in more detail at pages 331-344 of Design Patterns, by Gamma, Helm, Johnson, & Vlissides, Addison-Wesley 1995, ISBN 0-201-63361-2 which are hereby fully incorporated herein by reference. Those skilled in these arts will recognize that various other implementations of these algorithms and concepts may be developed without departing from the spirit and functionality of this invention. Additional background information can be found in Enterprise JavaBeans Specification, v1.1 (can be found at url=java.sun.com/products/ejb/docs.html), and in other sections of the book titled Design Patterns, by Gamma, Helm, Johnson, & Vlissides, Addison-Wesley 1995, ISBN 0-201-63361-2 which are hereby fully incorporated herein by reference. Alternative Embodiment An alternative embodiment of the BDK business applications server may be described as follows, using the context of how a developer and user would use this portion of the system. In an alternative embodiment, the developer's use is outlined in the context of a BDK development kit which would be provided by Applicants for use in developing applications which can run on the Platform and by way of indicating some details unique to the Platform through a description of a use of the Business Development Kit. In the alternative embodiment, the Business Server embodies a development kit framework which provides a set of interfaces and classes in the form of Java packages, identifies certain services that developers can rely on, and defines an application development model. The framework relies extensively on the server-side component model espoused by Java, namely Enterprise JavaBeans (EJB) components. Selection of EJBs as the server-side component model is driven in part by the requirements of reliance on open standards and backward compatibility. Using EJBs also enables integration with other Java 2 Enterprise Edition (J2EE) technologies such as Java ServerPages (JSP) and servlets that one would intend to use for web applications development. Furthermore, a number of EJB-enabled application servers available in the marketplace could be used to deploy the components so developed. In the alternative embodiment, the development kit classes and interfaces, the services, and the application development model are discussed in greater detail in the next three subsections. Classes and Interfaces The BDK interfaces and classes address the following needs. 1. Provide an additional layer of abstraction (by writing wrappers around base Java classes) to provide a richer level of functionality needed by SABA applications and to allow future modifications with minimal impact on the client application code. 2. Expedite component development by providing default implementations (that can be overridden) of certain required interfaces in EJB. 3. Define certain interfaces that must be implemented by classes used for specific purposes (an example is that a class must implement a certain interface if its instances are used in a JSP page). 4. Define certain classes that are necessary to provide basic services, such as data partitioning and logging, as well as utility classes for expedited application development. 5. To the extent possible, eliminate application server dependencies in areas where the EJB Specification is currently not vendor independent. In the alternative embodiment, the following discussion of is background for a discussion of the usage and types of EJBs within the context of the development kit described in more detail below. Metadata Support In the alternative embodiment, one of the facilities provided by the development framework is that characteristics of business objects can be varied across deployment. For example, for an attribute, one can optionally specify whether it has a required attribute, the list of values (LOVs) that the attribute can assume, its default value, and its minimum and maximum values. The values can be different across installations, as different customers have different requirements. To achieve this flexibility, metadata about the business objects and their attributes is captured in the system. In the alternative embodiment, some of the metadata that is currently captured about a class or an attribute could be dynamically determined using the Java reflection API. Examples include the parent ID and attribute count for business objects and attribute type for an attribute. The Java reflection API provides classes Class and Field that can be used to retrieve such information. Furthermore, instead of building a hashtable-based infrastructure for storing and retrieving attribute values, one can use methods like set and get in the Field class to operate directly on the attributes, which are declared as member variables of the class. The classes Class and Field by themselves, however, may not provide the rich functionality needed by certain applications. For instance, there is no way to indicate minimum and maximum values of an attribute in the Field class. Thus, what is needed is to create new classes that provide wrappers around Class and Field and capture the additional information. In the interest of consistency with previously used names while avoiding conflicts at the same time, two new classes may be used: SabaPlatformClass (inherits from Class) and SabaPlatformAttribute (inherits from Field). In addition to the functionality provided by Class (e.g., for getting parent class), SabaPlatformClass provides for such additional functionality as domain-based attributes and getting fixed vs. extended custom attribute counts. Similarly, SabaPlatformAttribute provides functionality for LOVs, default value, and minimum and maximum values. (As we will discuss later, the classes SabaPlatformClass and SabaPlatformAttribute themselves are beans--or, entity beans to be more specific--in this alternative embodiment system.) The classes SabaPlatformClass and SabaPlatformAttribute will not be used directly by users of business components (though developers of such components will use them). Typically, the user of these classes will be a class SabaPlatformObject. In some instances, SabaPlatformObject will make use of the functionality provided by these classes as part of an operation (e.g., when setting the value of an attribute, SabaPlatformObject will use SabaPlatformAttribute to determine the minimum and maximum value constraints). In other cases, SabaPlatformObject will delegate an operation directly to one of these classes (an example would be retrieving the superclass of an object). SabaPlatformObject implements a set of methods for getting and setting attribute values that provide a centralized point for capturing the logic for such things as auditing and constraint checking, and are used by subclasses of SabaPlatformObject. In this alternative embodiment, a component user will not interact directly with even SabaPlatformObject. Instead, the component user will deal with a specialization of either a SabaEntityBean or a SabaSessionBean, which are discussed in the next subsection. Beans In the alternative embodiment, components based on Enterprise JavaBeans (EJBs) will be a basic building block for developing applications using the BDK. Below we provide a brief overview of EJBs. Those skilled in these arts will understand that various books and documents on the "java.sun.com" web site provide additional details on this subject. There are two types of EJBs: 1. Entity Beans, and 2. Session Beans. Entity beans are used for modeling business data and behavior whereas session beans are used for modeling business processes. Examples of entity beans could be SabaClass (a training class, not a Java class), SabaPerson, and SabaRegistration. Entity beans typically would map to objects (tables) in the persistent data store. Behaviors associated with an entity bean typically would relate to changing the data in the bean. An example of a session bean could be SabaRegistrar, which uses the entity beans mentioned above and encapsulates the business logic associated with certain tasks, such as registering for a class. Session beans are not persistent, though changes in data of certain entity beans or their creation or removal could result from the actions of a session bean. A session bean can be stateful or stateless. A stateful session bean maintains state information specific to the client using it, such that results of invocation of a method may depend upon the methods invoked earlier on the bean. (An example of a stateful session bean would be SabaShoppingCart, which would keep track of items in an order as they are being added, to be followed by either placement of the order or clearing of the cart.) This is typically done by storing client-specific data in instance variables of a bean, which are then used by the methods to accomplish their task. A stateless session bean does not maintain any state specific to a client. An example of a stateless session bean would be SabaTaxCalculator, which provides methods for computation of sales and other taxes. In the alternative embodiment the development kit would provide two abstract base classes: SabaEntityBean and SabaSessionBean. (Whether a session bean is stateful or stateless is indicated in something called a deployment descriptor.) These classes implement the javax.ejb.EntityBean and javax.ejb.SessionBean interfaces, respectively. The intent is to provide a default implementation of certain required methods to enable rapid development of components, yet allow a component to override the default implementation of the methods it chooses. The SabaEntityBean class provides default implementations of the following methods: ejbActivate( ), ejbPassivate( ), ejbRemove( ), setEntityContext( ), ejbCreate( ), ejbLoad( ), ejbStore( ), and unsetEntityContext( ). Implementation of the ejbRemove( ) and ejbCreate( ) are discussed in the next subsection. The other methods in the list by default have an empty implementation. The SabaSessionBean class provides default (empty) implementations of the first four methods in the preceding list. SabaEntityBean inherits from SabaPlatformObject and provides attributes common to all the entity beans, (such as namespace) and has a method toXML( ) that ensures that all entity beans will provide an implementation for serializing their data to an XML representation. In other words, SabaEntityBean implements an interface ISabaXMLRenderable (explained later) and provides two convenience methods: findUsingRQL (String rql) and findUsingRQLURI (String URI) to locate specific entity beans using RQL. In addition to defining the bean class, to implement an EJB one also needs to define a corresponding remote interface, a home interface, and, for entity beans, a primary key class. The remote interface is the external world's view of the bean and is comprised of the business methods that the bean wishes to expose. The getters and setters for the bean's attributes are also exposed through the remote interface. A developer must implement these methods by calling the getAttrVal( ) and setAttrVal( ) methods available in SabaPlatformObject to take advantage of services like constraint checking and auditing. The home interface declares the life-cycle methods, such as those for creating, removing, or finding beans. The development kit provides two interfaces ISabaRemote and ISabaHome, which a bean can extend for defining remote and home interfaces, respectively. The ISabaRemote interface extends the standard EJB interface EJBObject and provides the following sets of methods:
.circle-solid. void setCustomAttrVal(String attr, <type>
value), and
.circle-solid. <type> getCustomAttrVal(String attr)
for Boolean, Timestamp, String, Integer, Float, and Double data types. The ISabaHome interface provides a layer of abstraction over the standard EJB interface EJBHome. The BDK also defines a class SabaPrimaryKey (a thin wrapper around the String class) which can be used by entity beans for defining primary keys. One final interface defined in the BDK for EJBs is ISabaXMLRenderable. This interface extends the java.io.Serializable interface and defines a single method, toXML( ). Only classes that implement this interface are eligible to act as return types of methods that are going to be invoked from a Java ServerPage. In the alternative embodiment the BDK would come with a few prepackaged beans. One is a stateless session bean named SabaPlatformLogin that can be used to authenticate a user. Another is an entity bean named SabaNameSpace, which encapsulates characteristics of a namespace, including its place in the hierarchy and the list of users who have access to entity beans in that namespace. The namespace is used for data partitioning and security purposes. Relationships Another area in which the BDK provides support is relationships amongst entity beans. In an object model, relationships between different classes are arranged in four categories: inheritance, association, composition, and aggregation. During implementation, the inheritance relationship is captured by extending a subclass from a superclass. The other three types of relationships entail constraints between the classes being related. For instance, a composition relationship implies commonality of life span (i.e., destroying the "whole" should result in destruction of the "components") and an association relationship implies referential integrity constraints (i.e., creating an instance of a class which refers to a non-existent interface of another class is not permitted). In an alternative embodiment, such relationships can be captured through constraints in the database. In the alternative embodiment, the BDK will provide a SabaRelationship class, that has attributes for the name of relationship, the type of relationship, the source class and attribute, and the destination class and attribute. The SabaRelationship class will encapsulate lifetime management constraints implicit in each of the different types of relationships. Thus, if an object is being removed and it is declared to have compositional relationship with some other objects, the SabaRelationship class will ensure the removal of the related objects. Similarly, when creating an object, the SabaRelationship class will ensure that referential integrity constraints are being satisfied. The SabaEntityBean class will delegate calls to the SabaRelationship class within its ejbRemove( ) and ejbCreate( ) methods. Any implementation that a component developer provides for these methods for a specific bean would have to call super. ejbRemove( ) or super.ejbCreate( ) as appropriate. In the alternative embodiment, an attribute capturing the list of relationships (where each item in the list is of type SabaRelationship) will be defined in the SabaEntityBean class. By default (i.e., at SabaEntityBean level), the list will be defined to be empty. When component developers create an entity bean by extending SabaEntityBean, they will be able to declaratively specify relationships between the bean being created and the other beans in the system. Additional relationships may be added to existing beans too when a new bean is created. In the alternative embodiment, besides lifetime management, the declared relationships could also be used for navigational purposes within the object model. As an example, consider a situation where the SabaRegistration bean is related to the SabaClass bean, which in turn is related to the SabaLocation bean. One would like to be able to retrieve attributes of the location (say, the map) of the class, given a registration. A new class, SabaCompositeRelationship will allow one to compose navigational paths in terms of basic SabaRelationship objects. Then, given a source object and the name (or id) of a composite relationship, the SabaCompositeRelationship class will be able to fetch the destination object(s). Vendor-Specific Wrappers In the alternative embodiment, when some areas within the J2EE specifications are still not standardized and are left up to individual vendors for implementation, additional facilities will be needed. To prevent vendor-specific implementation details from migrating into SABA code, the BDK would provide a class SabaJ2EEVendor that provides a wrapper around vendor-specific implementations. SabaJ2EEVendor provides static methods that can be used to perform activities in a vendor-neutral fashion in SABA code. An example method in SabaJ2EEVendor is getInitialContext( ), which encapsulates the logic for getting an initial context (at present, the mechanism for this is vendor-dependent). To use a particular vendor's implementation of J2EE specifications, one will have to provide implementations of the methods in this class. By default, the BDK will provide implementations of this class for a few selected J2EE servers. Miscellaneous Classes In an alternative embodiment, in addition to the foregoing, the BDK also provides the following utility classes that can be useful for developing components: SabaProperties, DateUtil, FormatUtil, LocaleUtil, SystemUtil, and Timer. Also, the following exception classes are supported: SabaException, SabaSecurityException, SabaFatal-Exception, AttributeNotFoundException, and SabaRelationshipViolationException. For logging purposes, the BDK provides a SabaLog class and for debugging purposes, the BDK provides a SabaDebug class. The functionality provided by the foregoing classes is similar to that available currently. The use of the various classes and interfaces discussed in this section is described in the "Application Development Model" section. Services A number of services are required by application developers to develop robust, flexible, and scalable systems. A number of these services are provided by the commercially available application servers that host the EJB components. In the following paragraphs we discuss the various services that an application developer can rely on and how these services might be used. Distributed Components One of the key ingredients for building scalable systems is the ability to distribute components. In the EJB model, different beans can be deployed on different computers transparently. Separation of interfaces from the implementation enables automated generation of stubs and skeletons that hide the details of network communications. A client application (or a bean that relies on another bean) (Subsequent references to a client application should be interpreted to be inclusive of beans that rely on other beans) uses a naming service to first locate the bean and then interact with it, thus making no assumptions about location of any given component. Naming As alluded to in the previous paragraph, before using a bean, it must first be located. All EJB application servers are required to provide Java Naming and Directory Service (JNDI) access for bean users. To use JNDI, a client application would typically first get an "initial context" (driven by properties such as where to find the EJB server, somewhat analogous to the JDBC connect string for locating a database), and then using the context, look up the home interface of the bean by its name. Using the home interface, the client can find a specific instance of a bean, create a new instance, or remove an instance. The naming service would be used and the interaction would be the same even if the bean instance is present locally (i.e., exists in the same Java Virtual Machine) instead of being deployed on a remote machine. The JNDI naming mechanism also obviates the need for the SabaClassRegistry mechanism that is used at present. The client application looks for a bean by a name (say, Authentication). Any bean class that provides the implementation of the remote and home interfaces can be deployed against that name in the application server. Thus, at one installation, the default bean class SabaPlatformLogin can be deployed with a name of Authentication, whereas at some other installation, the bean class SabaLDAPLogin can be deployed with the same external name to use a different authentication logic. Persistence One of the benefits of using EJBs is that component developers do not have to worry about persistence of data, as the container hosting the (entity) beans can manage such persistence. Automatic persistence service provided by the application server enhances the productivity of bean developers, is more efficient at runtime, and allows the bean's definition to be independent of the type of data store used for persistence (e.g., a relational database or an object-oriented database). A component developer will be responsible for declaring part or all of the attributes of an entity bean as persistent in its deployment descriptor, and then mapping them to fields in a database at deployment time. The interface and mechanism of such mapping would depend upon the application server being used. The bean is automatically saved to the persistent store when it is created by a client application using the create( ) method, and when the container decides to synchronize the bean's state with the database if the bean's data has been changed by the client application. The container's decision is based on such factors as transactions, concurrency, and resource management. The container will remove the data from persistent store when the remove( ) method is called by a client on an entity bean. Concurrency A component developer does not have to worry about concurrent access to an entity bean from multiple transactions (such as from several client applications). It is the responsibility of the container hosting the bean to ensure synchronization for entity objects. Indeed, use of the keyword synchronized is prohibited by the EJB Specification. Concurrent access for session beans is not meaningful, since by definition an instance of a stateful session bean can be used by only one client and stateless session beans do not maintain any data that needs to be shared. Transactions For transactions, an application developer has two options: 1) to explicitly demarcate the boundaries of a transaction, or 2) to use declarative transactional management available with EJBs. Use of declarative transactional management is cleaner and is strongly recommended. In this case, the level of granularity for managing transactions corresponds to methods in a bean. Instead of interleaving transaction boundaries within business logic, transactional attributes are separately declared in the bean's deployment descriptor (for a specific method, or as the bean's default) as one of the following six options: TX_NOT_SUPPORTED, TX_SUPPORTS, TX_REQUIRED, TX_REQUIRES_NEW, TX_MANDATORY, TX_BEAN_MANAGED. Details of these can be found in books on EJB. Security As discussed earlier, application developers can use a stateless session bean, SabaPlatformLogin, to authenticate a user. In the deployment descriptor for every bean, access control entries are defined which list the identities (users or roles) that are allowed to invoke a specific method (alternatively, an access control list can act as the default for all the methods in a bean). According to EJB Specification, each client application accessing an EJB object must have an associated java.security.Identity object (generally associated at login time). The general Security system used in the present invention was discussed in more detail above. Read/Write/Arbitrary Privileges Search To locate an instance of an entity bean, each entity bean provides a method findByPrimaryKey( ) in its home interface. In addition, other finder methods (which must be named in accordance with the pattern find<criterion>) can also be provided. With container-managed persistence, the container generates the implementations of such methods automatically at deployment time. The mapping of finder methods to the database is vendor-dependent at present, though a standardized syntax for the same is a goal of EJB 2.0 Specification effort. In the meantime, a developer can implement the finder methods in terms of findUsingRQL( ) and findUsingRQLURI( ) methods available in SabaEntityBean. Logging & Debugging A component may be used by multiple applications in an interleaving fashion. An application could have components distributed over multiple computers--how to assemble a unified log--use a "log server" bean--heavy performance price, impacts debugging class too. Turning on and off debugging on a component basis. Mechanics of how to do it without having runtime checks every time a method in Debug is called. What if one app wants a component to turn debugging on whereas another wants to turn it off. Application Development Model In the alternative embodiment, to develop an application using the BDK, an object model of the application domain should be first developed, retaining a separation between objects that represent business processes and those that represent business data. The two types of objects, obviously, map to session beans and entity beans in EJB parlance. A controller object, for instance, would indicate a session bean whereas an object that persists its data would indicate an entity bean. An application would typically also include UI components (such as JSP pages or servlets) which would use such business components. Thus, there are two primary roles from an application development standpoint: 1. component developer, and 2. component user. It is possible that an individual may play both the roles. Indeed, a component developer may need to rely on another component, and thus be a user as well as a developer. We will first look at the role of a component developer in the next subsection, and then look at the responsibilities of the component user. Finally, we will look at how an application can be packaged in this alternative embodiment. Component Developer To create a component, a developer needs to perform the following steps. 1. Define the remote interface of the component. 2. Define the home interface of the component. 3. Define the bean class. 4. Create the deployment descriptor of the component. As an example, one will build a simple SabaPerson component. SabaPerson is a container-managed entity bean useful for explaining some basic concepts in EJBs and the BDK framework. One then illustrates issues surrounding business logic coding, transactions, and persistence in a question-answer format. Note that for simplicity's sake, package, import, try/catch/finally, etc., statements are not included in the following code segments. The Remote Interface
public interface SabaPerson extends ISabaRemote {
public String getFullName( ) throws RMIException;
public String getFirstName( ) throws RMIException;
public String getLastName( ) throws RMIException;
public void setFirstName(String name) throws
RMIException;
public void setLastName(String name) throws RMIException;
}
The remote interface provides the business methods or the world's view of the component. In our case, we have a single method that a client can use to get the person's full name. Also recall that ISabaRemote already declares setAttrVal( ) and getAttrVal( ) methods for manipulating the attribute values (such as fName and lName declared in the bean class), so they don't need to be declared again. The Home Interface
public interface SabaPersonHome extends ISabaHome {
public SabaPersonEJB findByPrimaryKey(SabaPrimaryKey id)
throws FinderException, RMIException;
public Collection findByName(String fName, String lName)
throws FinderException, RMIException;
public SabaPersonEJB create(String fName, String lName)
throws CreateException, RMIException;
}
For container-managed beans, the container automatically provides an implementation of the findByPrimaryKey( ) method and generates the code for other finders (such as findByName( )) from an external description, which pending EJB 2.0 Specification, is vendor-specific. The Bean Class
public class SabaPersonEJB extends SabaEntityBean {
public String id;
public String fName;
public String lName;
public String getFullName( ) throws RMIException
{
return (fName + lName);
}
public String getFirstName( ) throws RMIException
{
return (String) getAttrVal ("fName");
}
public void setFirstName(String name) throws RMIException
{
setAttrVal ("fName", name);
}
. . .
public void ejbCreate(String fName, String lName)
{
this.id = IDGenerator.getNewID( );
this.fName = fName;
this.lName = lName;
}
public void ejbPostCreate(String fName, String lName)
{
// No action needs to be taken.
}
}
The bean class provides implementations for the business methods declared in the remote interface. Note that the fields in the bean class are declared to be public. The EJB Specification require this for container-managed persistent fields. Furthermore, this is also required by the setAttrVal( ) and getAttrVal( ) methods for fields that should be accessible via this methods (the methods use reflection to locate the fields). The consequences of such visibility are limited, however, because the user of a bean only interact with the bean through the home and remote interfaces. It is not possible for a client to directly assign values to or retrieve values from such public fields without going through the accessor and mutator methods defined in the remote interface. For each different signature of create( ) method in the home interface, corresponding ejbCreate( ) and ejbPostCreate( ) methods need to be defined in the bean class. The code for the bean class is consistent with this requirement. The Deployment Descriptor In EJB Specification v1.1 (which can be found at the java.sun.com web site), the deployment descriptor is an XML file that declares such things as container-managed persistent fields and security and transactional characteristics of the bean and its methods. The following example shows part of a deployment descriptor.
<entity>
<description>
This is part of the deployment descriptor of the
SabaPerson entity
bean.
</description>
<ejb-name>SabaPerson</ejb-name>
<home>com.saba.examples.SabaPersonHome</home>
<remote> . . . </remote>
<ejb-class> . . . </ ejb-class >
<prim-key-class> . . . </ prim-key-class >
<persistence-type>Container</persistence-type>
<cmp-field>id</cmp-field>
<cmp-field>fName</cmp-field>
<cmp-field>lName</cmp-field>
.
.
.
<container-transaction>
<method>
<ejb-name>SabaPerson</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Supported</trans-attribute>
</container-transaction>
</entity>
In EJB Specification 1.0, the deployment descriptor is a text file with a somewhat different format. The deployment descriptor is generally created using a GUI tool, generally supplied by EJB Server vendors. Additional information on deployment descriptors can be obtained from EJB literature and tool manuals. Depending upon the kind of business logic, there are different ways of encoding business logic in EJBs. Of course, implementation of the methods declared in the remote interface of a session bean or an entity bean encodes business logic. In addition, EJB provides "hooks" or callback methods for implementing additional types of business logic. We have already seen the ejbCreate( ) and ejbPostCreate( ) methods that one can use in a manner analogous to insert triggers in a relational database. Similarly, the method ejbRemove( ) (implemented with an empty body in SabaEntityBean and SabaSessionBean) can be overridden to encode logic related to deletion of a bean. For example, if we wish to encode the logic that if a person is removed, all the class registrations for that person should also be removed, we can override the ejbRemove( ) method within SabaPerson in the following manner. The ejbRemove( ) method is called just prior to actual removal of the data from the persistent store.
public void ejbRemove( )
{
/* Locate the home interface (regnHome) for the
** SabaRegistration bean (code not shown)
*/
Collection regns = (Collection)
regnHome.findByPersonID(this.id);
Iterator iter = regns.iterator( );
while (iter.hasNext( )) {
SabaRegistrationEJB registrn =
(SabaRegistrationEJB)
iter.next( );
registrn.remove( );
}
}
Other callback methods are ejbLoad( ), ejbStore( ),
ejbActivate( ), and ejbPassivate( ).
In the alternative embodiment, transactional integrity can be maintained as follows. Consider a session bean which, as part of its remote interface, has declared a method cancelClass( ) that encapsulates the business process of canceling a class. As part of class cancellation, we also wish to, say, remove the registration records of the persons registered for the class. The registration information is maintained by SabaRegistration entity beans. Hence, within the implementation of cancelClass( ), besides updating some attribute of the SabaClass entity bean to indicate cancellation, we would also encode logic for finding the SabaRegistration entity beans corresponding to that class and then removing them. However, either all these activities must succeed atomically, or no change to persistent store should be made (i.e., the activities constitute a transaction). This would be accomplished by declaring a transactional attribute of TX_REQUIRED for the method cancelClass( ) in the bean's deployment descriptor. If the calling client or bean already has a transaction started, the method will then be executed within the scope of that transaction; otherwise, a new transaction will automatically be started for this method. How Can In an alternative embodiment, complex data types can be persisted for container-managed entity beans as follows. Suppose there is an entity bean with an attribute that has an array of strings as a data type. Since relational databases do not support such a data type, one cannot directly map the attribute to some column in a database. However, at save time, one can potentially convert the array into a single String by concatenating the elements within the array and using a marker character to delineate various entries. Then, at retrieval time, one can look for the marker character and reconstitute the array. Entity beans provide two callback methods, ejbStore( ) and ejbLoad( ) that can be used for such a purpose. SabaEntityBean by default provides empty implementations of such methods. An application developer can override these methods within the definition of a bean and thus persist complex data types. In the alternative embodiment, every class in an application does not have to be a bean. Indeed, with the overhead of locating a bean through a naming service and going through the home and remote interfaces of a bean to perform useful work would negatively impact performance (though some servers will optimize the process for beans located within the same virtual machine). The application developers can implement selected classes as helper classes and not as beans. Sun Microsystems' J2EE Application Programming Model identifies certain instances where helper classes are applicable. One such example is dependent classes that can only be accessed indirectly through other classes (beans). Sun's J2EE APM offers CreditCard and Address classes as examples of a dependent classes. EJBs are packaged as EJB jar files that are comprised of the class files for the bean class, the home interface, the remote interface, the primary key class (if applicable), in addition to the deployment descriptor and a manifest. The jar file can be created using the jar application supplied with JDK, or by using some GUI front-end utility provided by the J2EE server being used. The deployment mechanism varies with the servers. For Weblogic server, an entry can be made in the weblogic.properties file; for Sun's reference implementation, the deploytool utility can be used to achieve this in an interactive manner. At present, the EJB Specification does not provide a mechanism for declaring such constraints, and this would have to be achieved programmatically in the create( ) and mutator method(s) of the entity beans. Component User As described above, in the alternative embodiment, a partial example of usage of a component was described in the context of business logic encoding. This section provides a fuller picture of how a component is used in an alternative embodiment, by either another bean or a client application. The primary steps in both the cases are the same: 1. locate the home interface of the bean; 2. using the home interface, create a new instance or find one or more existing instances of the bean; and 3. invoke the bean's methods to accomplish tasks. To locate the bean, JNDI is used. There are some variations in how JNDI calls are used with different EJB servers. Here we use the getInitialContext( ) method in the SabaJ2EEVendor class for locating
the SabaRegistration bean.
InitialContext ctxt =
SabaJ2EEVendor.getInitialContext( );
Object objref = ctxt.lookup("SabaRegistration");
SabaRegistrationHome regnHome = (SabaRegistrationHome)
PortableRemoteObject.narrow(objref,
SabaRegistrationHome.class);
Once the home interface of the bean is so located, we can use it to create new instances of the bean or find existing ones. In an earlier example, we had used the home interface for finding instances of a bean. Another example, this time for creating an instance, is presented below.
SabaRegistration regstrn = regnHome.create(personID,
classID);
Subsequently, we can invoke business methods of the bean simply as follows.
regstrn.setAttrVal(feePaid, true);
In addition to the foregoing, additional methods (implemented by the bean container) are available for getting a bean's metadata (from which its primary key class, remote interface class, etc. can be obtained), comparing two beans for identity, etc. Many of these methods are used in building tools, such as those for deployment purposes. If additional information about these methods is needed, please consult the available EJB literature. Those skilled in these arts will understand that various other alternative embodiments of a business application server system and related development kit for developers, may be designed around these basic concepts without deviating from the unique features provided by applicants in this invention. Security System In a preferred embodiment of the present invention, the Platform's BDK 519 provides an extremely powerful model for assigning security; that is, defining the sets of allowed operations that groups of users can perform. It supports both extremely sophisticated definitions of an allowed operation and a scalable model for assigning and partitioning security. Specifically, the following features are provided: Security operations can be specified according to either the general class of business object or to specific, individual business objects. Support for both shared security operations (view, update, delete, etc) and business-object specific security operations. Security operations can be assigned based on a customizable partitioning of business objects into domains. Security operations can be assigned based on either universal or domain-specific user groupings. Definitions The following concepts are central to the Platform's Security Model. A Security List Member is any entity | ||||||