226 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT two kinds of systems is highly instructive in regards to the specific middleware designs. IP networks are a prime example of distributed information. Rather than depend on global shared state or the correctness of every routing entry, IP utilizes mul - tiple distributed information bases located at the routers, switches and end points. AS - needed computation shares information with the local neighborhood. These distrib - uted properties facilitate large networks and global scale, However, these systems can - not easily locate specific information or control fine - grained resource allocations. Such networks require substantial extensions – such as networking middleware – to sup - port services - specific routing or bandwidth allocations. An important challenge is sup - port of such state - dependent services – or an approximation of them – without compromising the stateless nature of IP. Conventional operating systems, on the other hand, retain localized and detailed infor - mation. Low - level data structures organize the information and facilitates the man - agement of system resources, including the “virtual machine” concept. Higher - level descriptions allow exercise of very precise control over system behavior, for example by reference to a specific user’s privileges. However, as the number of processes, users, and other resources increases, the maintenance of this information becomes increasingly costly. Systems therefore migrated towards distributed architectures that localize information for related tasks. Micro - kernel operating systems, for example, exploit this principle. In a similar manner, the networking middleware combines multiple sys - tems. This views the networking middleware as a large and distributed micro - kernel operat - ing system. Linux is well - known for a similar approach. The power of Linux is the mechanisms to easily reconfigure the kernel while retaining Posix compliance. Linux’s popularity is not due to its stability, nor to serving as an alternative to Microsoft. Rather, it is the flexibility of modular design that readily reconfigures from the smallest to the largest implementation; similar capabilities are available through commercial Unix offerings as well. 7.3 Organization of the Middleware APIs We now shift to a specific set of communication middleware APIs that support the development, operation and management of services. These APIs are organized into general categories. These categories overlap and share common functions as required. For example, the callerID function is found in several categories. • Proxy Development (PD) for gate and core functionality. This includes packet fil - ter, security checks, events generation, user and service registries, as well as the proxy framework for developing new proxies. It includes a callerID capability for non - repudiable client identification even for untethered clients that do not have a fixed and unique IP address TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. O RGANIZATION OF THE M IDDLEWARE API S 227 • Software Development (SD) for peer and core functionality. This includes librar - ies for connections, the domain API, events, security, usage, and more features. It also includes a security framework (SF) API for credential and web authentica - tion management • Network Development (ND). This provides advanced firewall and QoS control through interaction with network element: including the DNE • Operations Development (OD). This supports creation and maintenance of domains. These APIs insulate the developer from the intricacies of the networking and compo - nents. Consequently, the services built with these broad API classes (see Table 5) adhere to the platform principles and can leverage the platform optimizations. By use TABLE 5: Network APIs and Component Availability Standard BrowserPurpose Gate Peer API Group NoYes Partial Routing Secure connections at designated service levels Authenti - cated Con - nections Active registries, connection manage - ment, non - repudiation interaction including events and usage. Yes Yes Yes User and Service access control Yes Access Control Yes Use, not specify Account hierarchy storing describing users, services Yes Yes Domain Use, not specify Security Framework Yes Yes Use, not specify Use, not specify Manipulation of user credentials and inclusion of secure methods Yes Usage Recording and Retrieval Non repudiation of action. Submit and retrieve usage records encapsulated in translucent cookies Yes Yes Yes Yes Naming Directory services such as LDAP and pri - vate proxy DNS MostNetwork Management Log, control, and measure components. Application management. Define, pub - lish, subscribe and receive events with descriptions Yes Use, not specify Yes Yes NoName/Value pair (NVP) Association Lists Toolkits Yes As needed NoNetwork Proxy framework, Service Devel - opment framework, Network Develop - ment toolkit, Security Framework toolkit TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 228 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT of the APIs one can develop any functionality and it will be reusable on many compati - ble architectures. One example is the SD for software development as shown in Figure 7 - 12. Consequently, the platform deployment is application - independent and optimized for available technologies. The ongoing developments such as OMG and JAIN may provide compatibility for even larger scale compatibility 7.3.1 PD – Proxy Development The Proxy Development tools describe APIs, sample code, tools, and documentation to enable application developers to write proxy applications for the middleware plat - forms, and allows programmers to network - enabled client software. The PD describes the internal side of middleware - enabled networks, and supports full interaction with the security and service functions including access control and dynamic firewall pro - tection. This enables the development of network proxies, allowing network mediation and enhancement of various protocols. In addition, network proxies are one technique to support scalability of various types of services, as well as fault tolerant services. These network proxies run on the gate machines in the GeoPlex Cloud. The PD enables developers to fully utilize and extend the cloud. The proxy framework fully supports custom proxies logically placed in the data path between a client and a server, as shown in Figure 7 - 7. It is an integral part of the mid - dleware platform. This allows the developer to easily and reliably add functionality in a fully - standardized manner. All new components share the same structure. Network proxies make use of various APIs as needed. The proxy developer can focus on the mediation facilities of the protocol, and let the rest be handled by the Development Framework The GeoPlex PD provides the following C and C++ APIs: • Proxy Development Framework • Access Control, including packet filter API • Active User Registry (AUR) • Active Service Registry (ASR) • Active Connection Table (ACT) • Usage Library • Directory Service • Network Management Service, including monitoring and events As a service architecture, it is important that the network provider be able to extend the cloud functionality with new network - based logic. Such custom tailoring may be designed as application level protocols that mediate data as it flows through the cloud. The proxy development framework provides managed multi - threaded support and grants such proxies the full power of the PD APIs. This includes systems management, TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. O RGANIZATION OF THE M IDDLEWARE API S 229 usage recording, encryption and other security services. These APIs can run, for exam - ple, on the gate architecture of Figure 7 - 6 as detailed subsequent chapters. Figure 7 - 6: Gate Components – Network Interfaces through Application Proxies Proxy development builds upon the firewall control and address remapping features. The development framework is programmed with the PD, and it provides access to the API sets listed above, including the packet filter, domain, and management APIs. The services are provided dynamically by a standard “plug in” process, technically dynamic load libraries. Once installed, they are protected by the network: the developer (or his company) does not have any risk of the proprietary code being copied or misused. The developer simply provides the custom proxy The network protects this resource by restricting use of the executable. All network components, including the custom proxy code, benefit from monitoring, usage tracking, and other network behaviors. Figure 7 - 8 shows the insertion of custom proxy code into the dataflow between the cli - ent - side and server side. The platform’s standard proxy framework dynamically sup - ports multiple custom proxies, for example through the data daemon (see Figure 7 - 6). Each proxy registers into the framework with the proxyRegister function. The frame - work then transparently places the custom code into the data flow, where it can medi - ate and enhance services. Proxies can register in either the “proxy” mode that interacts with two authenticated end points, as well as the “server” mode when only one end point is required. A “server” mode proxy responds directly to the client requests. These proxies can build application - layer protocols. The protocol requirements are defined during the registration and authentication of the service. This information is stored, as one might expect, in the secured cloud storage. Specifically, the service is represented by a service object within a domain, and the protocol can be an attribute of the service object. Application - layer protocols extend the standard protocols. This technique is known as proxy mediation. Proxies sit between the client and the server, for the express purpose of receiving a specific protocol and providing support. As Figure 7 - 7 shows, custom TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 230 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT Figure 7 - 7: Middleware Layers Supporting End - to - End Connection proxies build on the layered software design. The proxies can use all APIs, for example to check a user’s access rights, modify the packet filter, and retrieve information from the domain API. Every custom proxy can handle a large number of independent connections, each with its own “generation of storage” that remains associated with the connection for its entire lifetime. This storage is allocated to the custom proxy that mediates the connec - tion. The proxy can selectively access or modify the storage, and does this without con - cern for how many other connections use the same proxy. Each of the connections originates from a unique 32 - bit source IP and 16 - bit port (for IPv4), with the maximum number of simultaneous connections constrained by the host operating system’s capacity. While some end point devices may restrict the number of connections, it is typically not an issue for server - class machines. The new 64 - bit operating systems and hardware are designed with large numbers of connections. Data flows bidirectionally through the proxy, in keeping with the full - duplex nature of TCP service. The contents of each packet flows through the proxy framework and the Figure 7 - 8: Custom Proxy Code Installed with Proxy API TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. O RGANIZATION OF THE M IDDLEWARE API S 231 proxy code. The connection end points are appropriately referred to as the “connect” side and the “accept” side. The connection initially flows from the connect - side towards the accept - side, and the reply flows from the accept - side back towards the connect - side. Neither end point is constrained to a purely client or server role. Proxies share information in several ways. Multiple instances of the same proxy can directly access global memory of the controlling process. This is useful for example to share information between distinct connections that use the same application - layer protocol. Caching is one example but other forms of shared information include read/ write locks as well as other synchronization methods. A number of tools simplify the standardized development and effective management of these mediation components. These include logging, alerting, monitoring, and online control through management interfaces. These standardized elements are auto - matically incorporated into all proxies thereby ensuring coordination between system components. These functions are essential to all middleware networks. Systems man - agement and monitoring is discussed in detail Chapter 10. Figure 7 - 9: Custom Server Code Installed with Proxy API A proxy can also directly serve the connect - side requests, rather than provide the passthrough functionality just discussed. These proxies register as a “server” instead of as a proxy, as shown in Figure 7 - 9. This allows the custom proxy to provide all content to the client. Such proxies typically keep one or more TCP connections open to various resources. The proxy interacts with the resources on the client’s behalf and provides computation and communication - based responses as required. Proxies either modify or augment a data flow. Consider a simple proxy that resolves the problem of supporting a private password for the large number of users who can regis - ter to the cloud. The password protects some resource, for example a technical support service or a mail server. Password distribution and maintenance is error prone and dif - ficult to control in a large open user community. Rather than jeopardize the resource, a TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 232 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT proxy will provide the password whenever an authorized user requires it. The password can be transmitted by various means, of which a simple method is splicing it into the data stream where a dummy password occurs. A mediation proxy unlocks the resource by providing the password when required. This extends the password - based applica - tion from a closed domain to an open domain. The platform authenticates users and grants them the single - use of the password as required. A proxy is not limited to modification of the protocol flow. Activation of secondary ser - vices can be achieved by the generation of cloud events by means of the management APIs. This can activate highly sophisticated services. They are activated by a cloud component called the access daemon, which modifies the firewall packet filter to map traffic to the appropriate application - level proxy. The traffic is remapped back to its original destination processing by the proxy, as shown earlier in Figure 7 - 7. We dis - cuss this in greater detail later (see section 9.4.1.2 ”Proxy - Enabled Service Activa - tion”). 7.3.2 SD – Service Development and Peer The Software Development (SD) tools are composed of a set of Java APIs that develop - ers may use to build client and server applications for a middleware network. This pro - vides one method by which external components may gain a “toehold” to the cloud and directly request cloud services. These APIs use the SD, and can also extend a stan - dard client - peer. Figure 7 - 10 shows the relationship between the cloud and the SD application. The SD supports an authenticated control connection. This provides con - siderable insulation against network attacks, even in the public Internet, due to the inability of an attacker to determine the proper encryption keys (which are per - session and dynamic). Figure 7 - 10: SDK Integrates Client to Cloud - Managed Network and Services TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. O RGANIZATION OF THE M IDDLEWARE API S 233 The authenticated channel allows private and verified communication between the SD applications and the cloud. They may confidently request actions, and share informa - tion. The actions are invoked subject to authentication controls as shown in Figure 7 - 11. Figure 7 - 11: Open APIs Expose Platform Functionality 7.3.2.1 Peer Functionality There are three primary functions of the peer, and these are available to all peer - based services: • Establish a trust relationship between an end - point and its access Gate • Support information privacy through encryption of network traffic • Provide separate APIs for authentication, registration, account management, usage tracking, and the generation and reception of events on the network The SD supports both a standard and extensible environment, known as the peer. Cus - tomized applications can be developed with the SD in accordance with the needs of specific user communities and applications. The peer functionality is mediated by the cloud as shown in Figure 7 - 12. Peer applications fall into three architectural models: Peerlets, Monolithic Peers, and External Peer applications. Two of these, Peerlets and Monolithic Peers, differ only in whether the application controls the Java Virtual Machine (JVM). Peerlets extend the behavior of a standard GUI peer program, whereas the monolithic peers provide interfaces. External Peer applications, on the other hand, do not run in the same JVM as the Peer, and can be written in C or in Java. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 234 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT A subset of the Java - based functionality is made available for C language developers as well. It includes Peer software. This is installed on the client or server end - points of a supporting network The Peer contains all of the Java packages and C libraries needed to support client and server applications written for the network The SD adds docu - mentation, C header files, examples, and the Java Development Kit (JDK) from Sun Microsystems, Inc. Figure 7 - 12 presents some of the clients and services that could be constructed with the SD. The user console is currently available, and several custom clients have been designed or implemented. Figure 7 - 12: Clients Capabilities Extended through Common Platform with SD Peer - enabled applications may use cloud functions from outside the cloud. This is a powerful method to construct integrated services. Chapter 11, “Sample Consumer Ser - vices” describes an application of “virtual worlds” that combines multiple services with the SD. Users can authenticate to the network either with or without a Peer. If they do not use a Peer, it is referred to as “Peerless” authentication. Peerless authentication provides access to fewer cloud capabilities, and is intended for clients with web - browser access. Thus, this is not an option for developers who want to deploy a service on a supported network. Since some services may require peer - capabilities on an end - to - end basis, users who authenticate by Peerless authentication have access to fewer services than those users who use Peer - based authentication. The SD APIs provide the following functionality: • Peerlet management supports: starting, stopping, and communicating with Peerlets TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. O RGANIZATION OF THE M IDDLEWARE API S 235 • Connection management supports establishing authenticated connections to a network, announcing service availability (service announcements), and control - ling the platform encryptor • Registration, account management, and subscription supports registration and maintenance of user and service information that is maintained in a network Usage tracking supports the submission and retrieval of usage information Event generation and reception supports the delivery of events to and from dae - mons distributed across the network • External APIs support manipulation of the Peer from an external application, via the Peer Interface • • Although APIs are provided both in C and Java, the C API is restricted to the function - ality available through the Peer Interface, which represents a subset of the complete support available. 7.3.3 Network Development – ND Network Development (ND) uses a collection of APIs and tools that can be used to access the network infrastructure system. Users can access and customize the net - work’s API to meet their own needs. It supports the following functionality • Network measurement: resources, load, random - variable sampling • Network Control: • Full QoS & MPLS network adaptation environment with network interface APIs per IP architecture • Multicast support • Extranet support • E - Commerce support • Video conferencing support • Fax support • Network Interactions 7.3.4 Operations Development – OD The Operations Development (OD) supports rapid deployment of new IP services in a secure, scalable manner. The platform also provides a means of reliably identifying both clients and servers, and a means for adding value to standard IP protocols through a proxy framework. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... Informative, Non-cost and Genuine! 240 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT Figure 8-1: Logical Cloud: Network, Filter, Framework, Processes and Services Most of this chapter illuminates the fundamental issues that we encountered in the design, development and evolution of the architecture Such issues are important to application design for networking middleware, as well as forthcoming systems... General Credential-Issuance Framework The second major component of the networking middleware is the hierarchical active directory structure This combines an open API, known as the domain API, with underlying implementations constructed from the “best in class” in object-oriented databases These components are integrated into the middleware through distributed proxies, as shown in Figure 8-12 Figure 8-12:...236 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT The platform accomplishes this by integrating a wide variety of underlying (networking) functionality into a single unified whole Furthermore, the platform... the cloud The current chapter describes the use, effect and central interactions between these components We defer discussion of the engineering, mechanisms and complexities to Chapter 9, “Mechanisms of Middleware Components” 1 Global information shared between all POP elements 1.1 Authenticated Users and Services Global lists of authenticated components, addresses, and properties including security globs... custom levels 2.12 Application Protocols and Proxies System components and application support that extend the platform with customized proxies TEAM LinG - Live, Informative, Non-cost and Genuine! 242 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT 3 Monitoring and Management Subsystem monitors and manages components and network 3.1 Monitor and log Validate component status Support component logging... SNODE — EDGE GATEWAY FUNCTIONALITY 243 Figure 8-2: Edge Gateway: Filters and Proxies Extending Protocols and Interfaces The gate defines a security perimeter and a protocol mediation framework for the middleware network A dynamic packet-filter/firewall maintains this perimeter This restricts entry to authorized traffic exclusively, and may modify the destination of any packet The firewall provides extensible... information, and cloud status This versatile architecture provides the requisite flexibility to fully and quickly leverage new standards and products TEAM LinG - Live, Informative, Non-cost and Genuine! 244 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT Managed firewall secures portal into network-based services Authentication with standards-based methods (SSL, Radius, etc.) Optional stronger security... clients Nevertheless, the service machines are outside the logical trust boundary They are trusted only to provide a given set of services They cannot directly modify the security infrastructure or the middleware network Rather, they provide value-added services The service machines request cloud interactions by the use of standard APIs The firewall controls ingress traffic1 through a managed service-oriented... policies, as discussed in Section 9.2.4 The rules can also obtain fine-grain packet filtering by redirection of traffic to a daemon for further pro- TEAM LinG - Live, Informative, Non-cost and Genuine! 246 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT cessing Taken together, the first cluster of Table 6 defines a kernel supporting a powerful set of standard components The middle level consists of the... subsystem and usage subsystem Certificate authorities provide secure services to the cloud internally as well as to users of the cloud 8.2 Active Registries: Connections, Users and Services Networking middleware retains both dynamic and persistent information The dynamic state information describes the authenticated components including active connections, services, configuration, and security contexts . principle. In a similar manner, the networking middleware combines multiple sys - tems. This views the networking middleware as a large and distributed micro. offerings as well. 7.3 Organization of the Middleware APIs We now shift to a specific set of communication middleware APIs that support the development,