Development Component Types
Every development component (DC) has a unique type. This type determines the technology of the DC, the tools available for developing the component, the way in which the component is compiled, and the kind of products a DC creates during compilation.

Component types carry a unique name and a vendor ID. The number of component types can be increased, if necessary – even by third-party suppliers.
Development Component Types
Name |
Deployable Build Result |
Description |
Composite Application |
Yes |
Contains all elements required for a Composite Application Services project. These are Dictionary objects, metadata and Java classes. |
Content → Guided Procedures |
No |
Guided Procedures (GP) design time is a set of tools that allows you to model arbitrary business processes using a repository of software modules accessed in a uniform manner. These modules come pre-programmed with the GP framework and ready to use. They perform atomic tasks and can be combined into a working process. |
Content → UME Permissions |
No |
Extends the possibilities provided by the AS Java security roles. However, they are only supported when using a programmatic approach. |
Dictionary |
Yes |
Defines global data structures that are created in the database on the server, where the DC should be deployed. Since the data structures are created in a central database you should use unique names. To ensure this, the name server allows only certain prefixes for table names. |
Enterprise Portal → Portal Application Standalone |
Yes |
The model classes and structures for an Enterprise Portal Application project. These projects are automatically built in deployable archives (SDA). |
External Library |
No |
Enables you to use functions for development inside the component model that are available only as libraries and not as source files. You develop External Library DCs when you use the NWDI for development and want to use a function that is available to you only as a JAR file. To do that you have to: ... 1. Create a new DC of type External Library. 2. Create a public part of type Compilation and add the JAR file as a public part entity. You can now use the library to build other DCs. Because the DC type External Library itself has no deployable build result, you must deploy this DC together with another DC to make it available on the server. To do this, you need another public part of type Assembly. 3. Create another public part of type Assembly. Add these JAR files as a public part entity. To do that in the context menu of the public part, choose Manage Entities. 4. Put the JAR file into the public part. You can now wrap this public part into another DC type and make it available on the server. Other DCs then refer to the wrapped DC and not to the External Library. After the build, you can use the new DC just like any other DC. You can use it either separately or combine several External Library DCs into a software component. |
J2EE → EJB Module |
No |
Contains the model classes (for an Enterprise Application DC). When you create an EJB Module DC, the Developer Studio automatically creates a public part for assembly that contains the classes for the beans and a public part for compilation that contains the bean interfaces.
To add JPA (Java
Persistency API) support in the DC, you have to manually add JPA facet to the
DC project. More information:
|
J2EE → Enterprise Application |
Yes |
Combines Web Module DCs and EJB Module DCs into an enterprise application. |
J2EE → Web Module |
No |
Contains the files that belong to the view (and view-controller) part of an enterprise application project, such as JSPs, Servlets and Proxy classes for beans defined in an EJB project. |
Java |
No |
Contains arbitrary Java code. |
Web Dynpro |
Yes |
A container for one or more Web Dynpro components. |