NWDI 简介 Introduction to NWDI

NWDI 简介

 

 

转自：http://wiki.sdn.sap.com/wiki/display/Java/NetWeaver%20Development%20Infrastructure%20(NWDI)

Introduction to NWDI

Motivation

The SAP component model for Java was created to do

• Increase the productivity of Software developers by:
  • Removing the need to write build scripts. Instead, the build scripts are created automatically based on the component type. (Manually written build scripts are still possible as exception)
  • Providing a central build service that permanently offers a consistent pool of up-to-date libraries and other build results, making it easy to work on consistent and up-to-date libraries.
  • Removing the need to know details about the development landscape, repository locations, library versions by encapsulating this information in "development configurations". Similar to the selection of an R/3 development system, developers can select the environment (defined by the "development configuration") in which they want to work.
  • Supporting an automated deployment of the (re)built results into central test systems. This allows early integration tests during development, reducing the effort for later integration tests drastically.
• support developers by providing specialized tools and an automated workflow so that developers can concentrate on development without having to worry about delivery, deployment, versioning etc.
• improve management of software dependencies
• Increase reusablity and reuse of code segments by encapsulating functionality into small, reusable building blocks.

To achieve these goals the development of a software product was split into software components and development components.

Development Components

开发部件

 

Development components (DCs) are the reusable building blocks for software components. A DC is a named container for arbitrary objects, e.g. Java source files, JSPs, dictionary definitions, deployment descripters, etc. These contained objects are not directly visible to other components, i.e. the DC acts as a black box. You have to explicitly define "public parts" if you want some of these objects to be visible from the outside. A public part has a name and a purpose and contains a list of objects called entities. 

The purpose of a public parts is either compilation or assembly . Compilation means that other DCs can compile against the content of the public part, i.e. the public part defines the API of the DC. In the figure above, class X is contained in public part P1 with purpose compilation, therefore it can be referenced by classes in component A and the compiler will find class X, while it would not find class Y which is not exposed in a public part.

Purpose assembly means that other DCs can use the public part to assemble larger objects. E.g. a public part containing EJB classes can be used by an EJB Assembly project to assemble a jar file that can be used by an Enterprise Application project to assemble the final ear-file for deployment.

If a DC wants to use another DC it must explicitly declare this dependency. Dependencies are strictly hierarchial, dependency cycles are not allowed (as they would break the automated build).

DCs can also restrict their usage by defining an Access Control List (ACL), only allowing specific other DCs access to their public parts. An access control lists is either empty or contains a list of "Grants", i.e. a list of other DCs that are allowed access. If no grants are listed, any DC has access.

A DC can also contain other DCs. Contained DCs belong exclusively to their parent DC and are not visible to the outside at all. This can be used to encapsulate certain functionality without exposing any interfaces. Nevertheless the parent DC can expose objects that are visible in the public parts of the child DCs by including an entity reference to the inner DCs public part in its own public part.

A development component belongs to one software component at any given time. The assignment of a development component to a software component may however change over time.

A DC is always a buildable unit and its build can create a number of build results depending on the type of the DC and the number of declared public parts. A build result of a DC may be deployable directly into a J2EE engine, but not every DC produces such deployable build results. Some DCs just produce build output that is used (packed) by other DCs in order to create deployable results. Some DCs may produce build results that are installable ("deployable") into runtime environments other than J2EE like standalone applications or NetWeaver Developer Studio (as Eclipse plugins).

Software Components

软件部件

 

A software Component (SC) defines a deliverable, deployable unit. It consists of a number of development components (DC). A SC is basically only a logical shell around a number of DCs.

Software components may declare dependencies between themselves to grant or restrict dependencies between the development components they contain and those contained in other SCs.

Example: SC1 declares a dependency on SC2, thus component B has access to the public part of component Z. Since SC1 does not declare a dependency on SC3, component B can not use the public part of component II.

Development Configurations

开发配置

 

A development Configuration is the developers view of the development infrastructure. The developer sees the configuration containing "compartments" that in turn contain DCs. A compartment represents one state or version of a SC. The development configuration - or configuration for short - maps this view onto a build server (CBS) and one or more source code repositories (DTR).

Since development configurations contain all the information about

• the version of the SC
• the build server (CBS ) to use
• the repositories (DTR) where sources are managed
• the name server ensuring uniqueness of important names
• the software logistics server (CMS) which is responsible for consolidation, propagation and definition of the development landscape

the only thing a developer has to do to set up his development environment is to import a configuration. See "Importing a Development Configuration" for details on how to do this.

Design Time Repository

设计时库

 

The Design Time Repository (DTR) is a source code management (SCM) or version control system (VCS) like Perforce, ClearCase, CVS and others. The DTR operates on files or folders. All files that make up development components are stored and versioned in a DTR. The DTR is integrated with the IDE so that it will automatically add the required source files, property files, metadata files, etc. but not files that are generated at build time like Java class files, build logs, etc.

Information about the DTR server is included in the development configuration. Usually, you do not work with the DTR directly but only through the Active Team View, Inactive Team View, Local View and Activity View that provide some form of abstraction. All these views are part of the Development Configuration perspective.

There is also a special DTR perspective available that provides low-level access to the DTR. Remember that what you see in the Development Configuration perspective is an abstraction, i.e. the structures that are visible in these two perspectives look slightly different.

It is important to remember that the DTR deals with files and folders. Some objects that you deal with while developing on a DC might be stored in more than one single file, e.g. a WebDynpro application. This may cause unexpected behaviour from the IDE. E.g. opening the DC Metadata file (.dcdef) for editing does not automatically open the public part definitions of the DC for editing.

Component Build Service

部件编译服务

 

The Component Build Service (CBS) is a central service that builds your development components. When you activate an activity - automatically after check-in or manually from the Activation View - the CBS builds the modified DCs and all DCs that depend on them. If the build is successful the activity is made active, i.e. the changes are integrated into the version visible in the Active DCs View. You can check if your activation requests were successful in the Activation Requests view.

Information about the CBS is included in the development configuration.

Name Server

命名服务

 

The Name Server is a central server which is the naming authority ensuring unique names (e.g. for components, Java packages, context roots of web applications, DB table names etc.). When you e.g. create a new DC the IDE asks the Name Server for a name reservation for the name of the new DC. Only if this reservation can be obtained from the Name Server your new DC will be created otherwise you have to choose another name which is not yet reserved by some other component.

Change Management Service

变更管理服务

 

The Change Management Service (CMS) is a central service which is responsible for definition and administration of a development landscape consisting of one or several CBS and DTR servers and a Name Server. Development Configurations are created by a CMS administrator. In addition it controls propagation of sources and archives between different tracks (development areas for different development projects or different versions of development projects) in the same organization (e.g. SAP) or propagation to other organizations (e.g. customers, partners).

 

 

 

SAP NetWeaver Development Infrastructure

From Wikipedia, the free encyclopedia

Jump to: navigation, search

The SAP NetWeaver Development Infrastructure ("NWDI") combines the characteristics and advantages of local development environments – as usually provided in a Java environment – with a server-based development landscape that centrally provides a consistent development environment to development teams and supports the software development through the entire lifecycle of a product.

The Developer Infrastructure mimics the functionality of ABAP Change and Transport System (CTS). The aim is to control deployment of components in the system landscape in a standardized manner. NWDI can be used to import Business Packages from SAP and enables development teams to modify standard applications. SAP NWDI is also known as SAP JDI (Java Development Infrastructure). The latter term is considered to be obsolete.

Contents

[hide]

• 1 Components
• 2 Design Time Repository (DTR)
• 3 Component Build Service (CBS)
• 4 Change Management Service (CMS)
• 5 See also

[edit] Components

NWDI consists of

• Design Time Repository (DTR)
• Component Build Service (CBS)
• Change Management Service (CMS)

Sometimes people also count the following as part of NWDI

• System Landscape Directory (SLD), Directory service for SAP installations.
• SAP NetWeaver Developer Studio

The concept of the NWDI starts with a product and a software component (SC). The normal case is to have a one to one relationship between product and software component, one product is being developed and the relations between the components comprising the product are kept within a software component.

A software component comprises one or more development components (DC). A development component consists of a normal project created with the Netweaver Developer Studio, i.e. a [Web Dynpro] application. The software component can also have dependencies to other SCs.

All relations are defined in a SLD.

Since all DCs that makes a product is kept inside a software component, the relations between the DCs are intact and versions of the different DCs are always consistent in the SC.

To be able to develop a DC inside a SC, a track has to be set up in the NWDI to support that development.

[edit] Design Time Repository (DTR)

The DTR resemblance a filesystem and can be accessed via WebDAV. File and folder permissions can be configured for users or groups. Each file is version controlled and it's possible to branch or merge files. The main repository folder (ws) contains folders representing tracks in the NWDI. The files checked into the NWDI are files with no local dependencies. For example, the classpath file in a project refers to local jar files and are of no use for the Component Build Service when the project is build on the server.

[edit] Component Build Service (CBS)

When a file is changed in the Netweaver Developer Studio, an Activity is created together with a Request. When the changes are done, the request is checked in to the DTR, the activity is then activated which trigger the CBS to build the DC on the NWDI. Usually an ear or war file is created. When the activity is released from the Netweaver Developer Studio, the ear or war file is deployed to a development system via the CMS.

When the CBS finds dependencies between DCs inside the Track, all dependent DCs are rebuild automatically.

It's possible to use the CBS to rebuild a DC or even a full SC.

[edit] Change Management Service (CMS)

Change Management Service is used to maintain tracks and keep track of what version is deployed on different servers in the landscape. CMS can also transfer code between tracks. This is often used when creating tracks supporting development of general components, development of main components and finally maintaining deployment of full solutions.

Transferring code between tracks in order to achieve merge and joins between deployed production versions.

The CMS consists of layers on each track.

• Check-In : where initial source is loaded to the track.
• Development : represents the deployment to a development system. Changes are deployed on a DC level.
• Consolidation : represents the deployment to a consolidation system.
• Assembly : Stage to accept a change. Combines all DCs to a full SC. Version number labels are possible to set here.
• Test : represents the deployment to a test system. Changes are deployed on a SC level.
• Confirm : Confirmation stage before moving the change to production.
• Production : represent the deployment to a production system.
• System State : Gives an overview of the different versions deployed on different systems.

Each layer have a history and the possibility to go back to an earlier state.