In this section you will find some answers that surge at first sight and some other concepts needed to understand the rest of the document
- What is exactly a Gear?
- A Gear is a specific jLaBase package that contains a servlet and some Hibernate persistent classes with its own data model alike some other Java classes if needed (even EJB's). A Gear has complete functonability independent of the configuration of the system, they can have dependencies one from each other or don't. The otherside projects (jLaBase Enterprise, jLaBase Personal, jLaBase Admin Tools) will be release packages of gears and plugins for a general purpouse. Because each gear has its own data model, each gear has a unique name and defines a naming context where the System Gears can find and reference the entities of that model.
- What kinds of Gears must be implemented?
- Well, at this moment this uncertanly. The Gears system is modular and highly customizable, there should be some standart Gears that will do the typical administrative jobs, but the system administrators could need the use of more specialized ones to do some rutinary jobs that a home user will not need to do. There should be some Gears that will need authentication from the user and others won't. Even though, some Gears that require user authentication can work as well with an anonymous identification. In the section Planning you will find the future Gears designed and to be implemented, the next list is a general calissication:
- System Gears
- EJB Gears
- User Gears
- Where is the Bussines Logic?
- The Bussines Logic is inside the Gear, we will do a difference between Gears and EJB Gears. An EJB Gear is a special that holds the Bussines Logic of a group of operations, while the other ones are low-level Gears or User Gears that require a litter amount of resources than the EJB ones (because they don't work with EJB's).
- Why Gears?
- Modularity. Single groups of developers can work in a single gear without caring about the database engine or the system different configurations. In this way the amount of Gears will grow by the time as project grows too.
- What is the different between a Gear and a Plugin?
- The difference is that a Gear is a kind of plugin. Our system will work with eclipse-like plugins that can extend its functionability in more different ways: Graphical UI's, tools, etc. and Gears. So, a Gear is a kind of plugin which responds to the first definition. The reason of using eclipse-like plugins is that there is many people are at this moment developing eclipse plugins, they are easy to use and very versatiles.
This concepts are used by most different people with a specific meaning. Here is our own specfication for those concepts.
- Data Server:
- For all of us, a Data Server is a machine that has inside its file system one or more (it depends of database engine) files that contains tables, views or relations (with or without other database objects); all related between themselves, so it is a single unit of data. The Personal Edition can manage more than one data servers but not more than one at the same time.
- Data Environment:
- The complete network of an enterprise is the top-level data environment. This environment is compounded by one or more dataservers (with its jLaBase Gears mechanism) which store data related between them. In this network can exist other sub-environments relative to the main data environment of the enterprise, so each data environment defines a naming context. The initial context of the network is the Top-Level Data Environment.
- Dataset:
- Amount of data retrieved from the data server or an XML file. A Dataset can be any kind of query the user request. The Gears mechanism will work to retrieve all the data needed to respond the request. The response of the query against the gears mechanism is an XML file that can be displayed in any web browser. Using XML files to share data between the different gears and servlets will be able to do exports in lite files and recover the information later.
The are some predefined standart groups in the system and the administrator(s) must complete them adding the needed ones. Each group handles the perssisions of a group of users over a table or group of tables, the environment will take care allways to most restrictive case of permissions for a single user. The owner of the tables is the "leader" of a group of users, the rest of users of the same group are restricted with the group permissions, if a given user group doesn't have anyone as "leader", then all the users of that group are restricted by the same permissions. Here you will find an UML diagram of the different groups as actors in a database environment. The predefined user groups of the environment are:
- jlbroot:
- The group of the user administrator, the leader of this group is the root user, the rest of the users of this group depend of what the root user decides. This is the "leaders" group too. Each other group that needs an special user as "leader", this last one must to be a member of the jlbroot user group.
- jlbseller:
- The group of users who have permissions to store new Sales/Borrow, Supply, etc. relations. In some cases, users of this group will have permission to store new Articles, Services, Customers and Manufactors; this permissions are restricted by the root user or by the leader of this group. The leader of this group should be person in charge of the sales department. This user group is not very usually in a home environment.
- jlbcustomer:
- A group of users registered in the server who can do searchs, query sales/borrows, do reserves and buy articles. Obviously, this group and the next one have not any leader because it is not needed.
- jlbvisitor:
- A group of users not registered in the server, they can do searchs and queries, but they can not buy or rent any article or receive any service.
Inside a corporative structure this user model is easyly transportable to the relations between a employee, employment and departments. The permissions and users are stored in simple tables which are referenced from any other that needs any kind user relation.