An EGL application is organized in one or more projects, each of which is a physical folder in the workspace. A project contains an EGL source folder that is provided for you, and that folder contains one or more packages, which in turn contain EGL source files. This hierarchy is basic to your work in EGL: a project, then an EGL source folder, then a package with EGL source files.
The EGL source files include EGL parts, which are type definitions that you create. For example, a Service part contains logic, and a Record part can be the basis of a variable that you declare in your Service part.
myRecord MyRecordPart{};
One project can reference the parts in a second project, but only if the EGL build path of the referencing project identifies the referenced project. Again, this tutorial gives examples. However, in all cases, avoid using the same package name in different projects, as that usage can cause problems in name resolution.
You can include all your code in a single project, but the separation shown here lets you easily deploy the two kinds of code in different ways.
Parts in one project can use parts in a different project. EGL uses a build path to search for unresolved references. Later in this lesson, you will add the PaymentService project to the build path for the PaymentClient project.
To create an EGL project to contain the service:

An EGL Rich UI project includes many shortcuts to speed the development of a user interface for the web.
To create an EGL Rich UI project:

These three projects contain widgets and other support files that you use in creating a Rich UI application.
You must change the build descriptors for the project so that the logic you write there can access a database.
To edit the build descriptor:
In the next lesson, you develop some of the Rich UI application and view your prototype code in action.