Net-Centric Guidance SV-

Augmented Product Purpose. In a net-centric architecture, the SV-2 is used to 1) detail the communication paths used by the interfaces between services, systems, and system nodes, 2) highlight critical communications infrastructure that is connecting to or shared with the NCE, and 3) depict the physical mechanisms that host services provided to the NCE.

Net-Centric Product Description. The SV-2 traditionally documents the specific communications links or communications networks and the details of their configurations through which systems interface. Accordingly, in the NCE, the SV-2 contains a detailed description of how each SV-1 interface is implemented and depicts communications systems, links, protocols, standards, and networks that support the delivery of information and capabilities to services and consumers in the NCE. It is important to note that in a net-centric SV-1 a system node containing services should have interface lines that highlight the use of internet protocols (i.e., HTTP, SOAP).

Services are a key means to share information and functionality in the NCE through

published service interfaces, as depicted in the SV-1, that enable interoperability among

applications across the NCE. The details of how the service interfaces are physically

implemented at the network layer can be captured in the SV-2 by depicting different views of the communications layers between services. The SV-2 provides a more detailed communications

analysis and can be depicted in separate SV-2s to show different layers of the communications network. For example, network layer messaging capabilities such as SOAP intermediary message routers can be captured in the SV-2. As part of the net-centric SV-2, the DoD-wide SST should be used to the extent possible for describing each service. Regardless of the precise SST, the necessary minimum subset of information from the SST for each service must be captured in the SV-2:

o Service Access Point Information Category includes information that describes the

message format and transmission protocol, URL, the operational status and point of contact, and the lifecycle step of the service (i.e., development, testing, or production).

ƒ This would include information about the host layer that depicts hosting locations for services and lists the service implementations they are hosting. Implementations that should be represented include offered services that appear in the net-centric SV-1, enterprise service bus

components, and infrastructure services.

o Quality Model Category includes information on the security requirements of the

service, the QoS levels, and any performance considerations for service deployment.

ƒ Service Level Specifications identify performance specification details that

stipulate expected service performance under identified circumstances and quality of service levels. This would include information at the physical layer that depicts physical components of communications channels between known providers and consumers and should illustrate network hops, bandwidth limits, and connectivity environment.

In addition to the SST elements, DoDAF v1.5 extends the service interface specifications, to include a Service Provider element. The Service Provider element identifies the organization

providing the service (the organization that is the Service Functionality Provider operational role from the OV-2).

Separate SV-2s that show different communications layers can assist in understanding and depicting the complexity of the interoperability among applications and services across the NCE. The different depictions of the SV-2 should be linked among different layers to provide program managers a high-level view of the communications infrastructure.

Documenting these various aspects of net-centricity in the SV-2 products will describe service requirements on the capacity, timing, and reliability of services composing the architecture.

Figure 5-14 illustrates an intranodal version of a net-centric SV-2 from the viewpoint of a single node that appears in the net-centric example SV-1. In this example, the single interface

Data

Processing Location

Web-Portal System Web-Portal System Sensor System

Data Service Family

Playback Service Storage Service

Data Processing Service Family

Conversion Service Validation Service

Sensor System Data Service Family

Playback Service Storage Service

Data Service Family

Playback Service Storage Service

Data Processing Service Family

Conversion Service Validation Service

Data Processing Service Family

Conversion Service Validation Service TERRESTRIAL CONNECTION TO DATA ANALYSIS LOCATION NODE TERRESTRIAL CONNECTION TO EIEMA LOCATION NODE SATELLITE CONNECTION TO SENSOR DEPLOYMENT LOCATION NODE TERRESTRIAL CONNECTION TO SENSOR DEPLOYMENT LOCATION NODE

Enterprise Service Bus (ESB)

Figure 5-14: Notional Example: SV-2: Layer 2 Example

appearing in the net-centric SV-1 notional example between the Data Service Family’s Storage Service in the Data Processing Location and the Data Service Family’s Streaming Service in the Sensor Deployment location is supported by two communications paths, a satellite connection and a terrestrial connection. Also highlighted are interfaces to locally hosted ESB components, which provide service related messaging and transport mechanisms internal to the node. Specifics on communications networks and protocols should be attached as metadata to each communication path.

5.2.4 CADM Support for SV-2

SV-2 is stored as an instance of Document with its attribute ArchitectureProductTypeCode = SYSTEM-COMMUNICATION-DESCRIPTION. To capture the information content of the SV-2 product in CADM v1.5, each of its components are linked to it via ObjectVersionAssociation (see Volume III for details). The subject of each SV-2 is a set of Nodeinstances and their associations defined as a specific Network. In CADM v1.5, instances of the entity Network can be linked to

Capability, System, and InformationTechnologyStandard. The link to Capability serves to record quantifiable measures of performance (MOPs) for components of the Network.

Additional characteristics cited for a specific SV-2 are specified using the following entities, as applicable:

• CommunicationMedium

• EquipmentType (a subset of MaterielType)

• Materiel and its associations to other instances of Materiel, as well as associations to Organization

Nodal diagrams prepared for SV-2 can also be linked to IconCatalog in the CADM to associate graphical representations to the content of SV-2, and enable, for example, the specification of which fields shall be presented when users highlight (click) an icon. To that effect, the attribute NodeIconCategoryCode in IconCatalog can be set to LINK-ICON or NODE- ICON.

In CADM v1.5 Network can be linked to Architecture, Node, other instances of Network,

Capability, CommunicationMedium, Organization, and NetworkType. Each Node can be related to

other instances of Node as well as any of the following entities as required:

ActivityModelInformationElementRole, CommunicationMedium, DataItemType, Capability,

Organization, OrganizationType, ProcessActivity, System, and Task (not all are shown in Figure 5-15).

SV-2 can be populated with electronic addresses for each fielded communications device by linking them to instances of the entity ObjectByReference with its CategoryCode = INTERNET- ADDRESS.

Because many other CADM entities involved in SV-2 are the same as for SV-1, their discussion is not repeated here.

Figure 5-15 provides a high-level diagram from the CADM showing key entities that are used to store architecture data for SV-2 in a CADM-conformant database.

Figure 5-15: CADM Diagram for SV-2

5.2.4.1 SV-2 – Data Element Definitions

SV-2 depicts the implementation of the interfaces from SV-1 as specific communications systems, communications links, communications paths, or communications networks and the details of their configurations through which the systems interface. Table 5-2 describes the architecture data elements associated with SV-2.

SV-2 Information Space