Show TOC

SAP's Component ModelLocate this document in the navigation structure


Let's think of the steps of a complete development process. The final goal of the development is to have a complete and working product. The product consists of different parts that we call software components (SCs). During the development process, some of these SCs are already available, while some are expected to be created. To work on your part of the product, that is, to work on your SC, you need to know the exact SC you have to work on plus the minimum set of required SCs that your SC depends on so you can successfully develop and then test your own SC. In this SC you develop your projects as usual, but here these projects contain additional metadata, describing interfaces (that is public parts) and dependencies between projects (again enhancing the reuse). We call such an enhanced project a development component (DC).

In SAP NetWeaver, the Java-based software development is usually performed in the SAP NetWeaver Developer Studio, which is based on the standard Eclipse Foundation development environment. In the Developer Studio you will find a number of plug-ins that you can use in software development, starting with the pure Java development right up to SAP's specific technologies.

In the SAP NetWeaver Developer Studio, you will find toolsets that support you with working with components, whereas with the SAP NetWeaver Development Infrastructure (NWDI) you get full support with setting up and managing a development environment for the whole team.

Figure 1: SAP's Component Model Element Overview

SAP's component model deeply relates to the development process by its structuring units - the DCs. From a technical point of view, each DC simply represents a Java project (we call a development object the part of the DC that you change or develop) plus some metadata (the software unit itself, for the relations with the different DCs and the parts they share) generated by the SAP plug-in you are using in the Developer Studio. In other words, you develop as usual Java software in Java projects, Web Dynpro projects in Web Dynpro DC and so on, depending on the type of development project you want to work on.

SAP's component model defines the exact relations that each DC can have with the other DCs. In brief, a DC has the following specifics:

  • DCs can depend on one another and use each other. This allows you to organize your software in small, comprehensive and reusable units which are based on each other and communicate using well-defined interfaces. The dependencies between DCs are defined together with the DCs. To define that a DC wants to use the functionality of another DC, you have to explicitly declare it.

  • A DC's inner life is based on the black box principle. Its development objects are not visible to the outside world.

  • Development objects are automatically built before they can be deployed in a runtime system. The build process itself is based on the current DC type.

    To build the available DC types, the Developer Studio provides build scripts which relieve you of the task of writing the corresponding make files, ANT files, and so on.

  • Besides development objects, one DC can contain other DC, that is, DCs can be nested. An inner or child DC is invisible to the outside world and protected by the outer or parent DC.

  • Every DC has a unique name.

Of course, developing a software product also means organizing these DCs as different parts of this software. There must be an easy approach to consolidate these parts for the final product. SAP does this by organizing the DCs into what are called software components (SCs). You can think of an SC as a part of the whole product that can either have a life cycle on its own or have as many dependencies as are required for its life cycle to other SCs of your product. Also, you can mark each SC you have with a version number, that is, SCs allow versioning of the software.

The SCs combine DCs into larger units for delivery and deployment:

  • Once you develop an SC, you can make it available for usage from other SCs. This allows you to define different logical formations of SCs, that is, you can form different software layers. Each SC, once it is ready, can be used by other SCs in the other layer(s).

  • If one SC depends on another SC, then the first (using SC) can use all DCs of the second SC (the used SC).

  • SCs cannot be nested into each other.

  • Since SCs do not have development objects of their own, they define dependencies exclusively for the DCs assigned to them.

As a consequence for DC:

  • Every DC must be assigned to exactly one SC. The assignment of DCs to SCs is not static and may change over time. SCs do not define public parts: all assigned DCs are automatically defined as public.

  • A DC can use another DC from a different SC only if its own SC defines an appropriate dependency.

  • DCs can restrict their use from certain SCs using access control lists (ACLs).

  • Nested DCs always belong to the same SC as their parent DC.

SCs have globally unique names which are structured in the same way as for the rules for DC names. Names of SCs consist of a vendor ID and only one segment, such as .