Requirements analysis

When designing an architecture for NBD, it is important to note that constraints on network availability and topology, available services, intended users and required robustness all vary with each deployment, and thus add to the complexity of such an architecture.

Summarizing the discussion of different operational levels (see Figures 1.1(a) and 1.1(b)) from the previous chapters, we can state the following about the three levels:

We know that the strategic level has a large fixed infrastructure and hosts a large number of services.

In these networks, there will be hundreds to thousands of nodes. This domain requires solutions that can scale to a large number of users and contain information about a large number of services.

The tactical deployed level can use a mostly fixed infrastructure. Such networks constitute the backbones of the deployed networks, for example a local HQ. However, these deployed networks need to communicate with other networks both at the same operational level and with other networks higher or lower in the hierarchy. For such communications, they employ radio or satellite links, which are prone to disruptions. Thus, at this level, we have fairly large fixed networks, but some dynamicity is expected due to their interconnection with unreliable links. The networks are large, with hundreds to thousands of nodes and services. At this level, we need solutions that can scale to a large number of users, and that can handle some dynamicity.

The tactical mobile level, the lowest level in the hierarchy which constitutes the so-called disadvantaged grids, differs a lot from the two other levels higher up in the hierarchy. Here, the

Architectural property Operational level

Premise: Solution must support a federation of systems All

Premise: Solution should use Web services technology All

Always use standards when possible All

Support for radio silence Tactical

Support for limited bandwidth Tactical

Support sudden disruptions Tactical

Support low MTU Tactical

Should not rely on TCP Tactical

Should not rely on IP fragments Tactical

Table 3.1: Requirements analysis stating premises and properties that must be fulfilled, and to which operational level(s) each item applies.

networks are small, each network with perhaps four to twenty nodes, and a small, mission specific set of services (sensors, positioning information, etc.). The networks use wireless links with all the drawbacks and limitations we discussed in Chapter 2. At this level, we need a solution that can handle a highly dynamic environment. It should also be resource efficient, since resources are scarce.

As we can see, the different networks may call for different solutions. In the fixed networks, scalability is the most important aspect. In disadvantaged grids, on the other hand, we need solutions that can handle high mobility and at the same time minimize resource use. In these networks, conserving resources and supporting mobility is much more important than scalability, since disadvantaged grids usually are very small networks compared to those higher up in the hierarchy.

Hence, we have identified several key architectural properties necessary for Web services to function in dynamic environments. These properties (i.e., the requirements analysis mentioned in Section 1.3, item number one) are summarized in Table 3.1. In a NATO federation of systems it is unrealistic to expect that one can choose and deploy a unified solution. Furthermore, the demand that standards should always be used when possible is very important for interoperability reasons. In later chapters when we evaluate different solutions, this property is one of the most important ones.

3.6 Summary

Interoperability is crucial when attempting to fully realize NBD, but achieving such interoperability is a considerable challenge given the large number and heterogeneity of the different systems currently being used, and the scarcity of resources on the tactical level. Middleware is an abstraction layer that can conceal the heterogeneity of underlying hardware in a distributed system, and thereby represent a solution to this challenge.

Web services are the most common way of realizing a SOA. However, Web services are still far

from being mature enough for playing the role as a "middleware of middlewares"; especially on the standardization side, much work remains since (e.g., lack of several important QoS aspects).

Standards are important for interoperability, and it is important to avoid proprietary solutions to avoid vendor lock-in. The greatest strength of Web services technology is that it is interoperable across different operating systems and different programming languages. You can connect systems running on OS X, Windows, or Unix, and applications implemented using Java, Python, Microsoft .NET, and others. This is the main reason why Web services are in such widespread use today. Thus, in this report we focus on employing established standards when possible.

The core standards, XML, SOAP and WSDL are widely supported. They form the foundation of Web services, and are the absolute minimum one needs to support in order to use Web services as a message oriented middleware. You use the WSDL to specify the service and client interfaces, and SOAP to convey messages between the service and client instances. XML is used for "everything"

in the Web services world, since it is the language used to formally define every schema used in the Web services standards and specifications. Some areas, such as interaction and description (see Figure 3.1), have standards and implementations that are well developed and interoperable.

However, topics like QoS and composition are still lacking standardization and non vendor specific implementation. Thus, it is possible to start employing the mature standards now, and modularly expand the middleware functionality as additional standards gain widespread use. This is where WS-I plays an important role. To ensure interoperability between implementations from different vendors, a standard should be addressed by a WS-I profile.

In the examples we have seen that commonly only the "bind" operation is performed in civil applications. We have also seen that Web services can bring added value to military applications.

The main drawback of Web services is the overhead: XML is text based, and thus a quite verbose way of encoding data. This can be a problem in networks with low throughput. Also, since HTTP/TCP does not always work in tactical networks, there is a need to address the particular requirements of disadvantaged grids as well. As we will discuss in subsequent chapters, there are techniques that can be used to optimize Web services in different ways. In the next chapter, we will investigate techniques that can be employed for optimizinginvokingWeb services for tactical networks.