Figure 65. Situation2A:ApplicationInteroperabilitywithApplication-LevelTranslation
If the customer has the flexibility to recode part or all of the application, there
are many choices. There are basically two levels of complexity involved. The
first level of complexity involves the choice of a common API and Application
Services level, therefore minimizing the amount of conversion that must take
place at these levels. The second level of complexity involves the selection of a
common transport protocol.
If one of the Application Support-level choices shown in Figure 66 on page 106
is selected, these technologies would provide the consistent API and
Applications Services-level required, as well as permitting the utilization of more
than one transport protocol, hopefully a transport protocol that is compatible with
the existing user network.
There may also be situations where the customer chooses an industry standard
API and Application Services approach, such as RPC for TCP/IP, but has a
problem with the transport network (for example, OSI). A mixed-protocol stack
approach, such as with MPTN or mixed-protocol standards (RFCs or other
standards), might be appropriate to transmit the data across the network, and
then the user code would still need to convert any data format differences at the
highest layers. Encapsulation could also be used for this data transmission,
assuming that the user application is still prepared for the upper layer
conversions.
Chapter 3. Typical Customer Situations
105
Pdf password - C# PDF Password Library: add, remove, edit PDF file password in C#.net, ASP.NET, MVC, WinForms, WPF
Help to Improve the Security of Your PDF Document by Setting Password
annotate protected pdf; add password to pdf document
Pdf password - VB.NET PDF Password Library: add, remove, edit PDF file password in vb.net, ASP.NET, MVC, WinForms, WPF
Help to Improve the Security of Your PDF Document by Setting Password
add password to pdf file without acrobat; a pdf password
Figure 66.  Situation 2A: Technology Choices
As before, the marketplace will determined what is actually available for a
particular desired combination of application services, transport protocols and
operating systems. Considerations which should be kept in mind as these
technologies are evaluated include:
Multi-Protocol Servers
•
Is an end-to-end connection required? Or is it adequate for the server to
provide translation capabilities for various applications?
•
Is this a mission-critical application which should be dependent on a
potential single point of failure?
•
How much traffic can a particular server handle efficiently? How can
additional users be handled?
•
Can additional transport protocols be supported? Can additional
applications be supported?
Remote APIs
•
What APIs are supported over which protocols - does the correct
combination exist?
•
Does this “skinny client” provide enough functionality to satisfy the
application requirements?
Middleware
•
Does this middleware implementation exist on all required operating
systems in the end nodes?
•
How much flexibility does the middleware application programming
interface give to the application developers?
•
What are the extra facilities provided by the middleware implementation
in terms of directory, security, and recovery?
106
Introduction to Networking Technologies 
Online Remove password from protected PDF file
Online Remove Password from Protected PDF file. Download Free Trial. Remove password from protected PDF file. Find your password-protected PDF and upload it.
advanced pdf password remover; create password protected pdf reader
C# PDF File Permission Library: add, remove, update PDF file
Convert Jpeg to PDF; Merge PDF Files; Split PDF Document; Remove Password from PDF; Change PDF Permission Settings. FREE TRIAL: HOW TO:
password pdf; convert pdf password protected to word online
XTI
•
Is the new transport protocol a currently available XTI protocol, such as
TCP/IP, NetBIOS, or OSI?
•
If this is a new-customer developed application, can communications
software and compilers be found that utilize this interface for the
currently installed hardware and operating system platforms?
•
If flexibility is desired in this customer-developed application, can the
application be coded with just the necessary subset of the transport
functions?
•
If an off-the-shelf purchased application, has it been coded to utilize the
XTI interface? If so, does it support the transport protocol you want?
MPTN
•
Do MPTN implementations exist for the necessary protocols?
•
If MPTN implementations exist for these protocols, do they exist on the
required operating system platforms in the end nodes? If not, do they
exist for operating system platforms which could be used as a gateway?
Mixed-Protocol Standards
•
Is it a supported application/transport combination currently supported
by the RFCs or another standard, such as a NetBIOS or OSI application,
which needs to run over TCP/IP?
•
Do the protocol stacks installed in the end nodes support the standards?
Encapsulation
•
Will this encapsulating software be placed in the end nodes? Or will it
be placed in a separate node, requiring additional hardware?
•
How is the encapsulation actually performed? Are Data Link Control
protocols properly terminated and emulated? Are the transport-level
protocols properly emulated? Is filtering of unnecessary packets
performed?
•
What are the performance characteristics of this encapsulation software?
Is this acceptable?
•
How are the different network addresses handled? What directory
services exist?
•
How expandable is this approach if the network grows and more nodes
are added?
Chapter 3. Typical Customer Situations
107
VB.NET PDF File Permission Library: add, remove, update PDF file
Convert Jpeg to PDF; Merge PDF Files; Split PDF Document; Remove Password from PDF; Change PDF Permission Settings. FREE TRIAL: HOW TO:
pdf password; add password to pdf file with reader
C# HTML5 PDF Viewer SDK to view, annotate, create and convert PDF
Support to add password to PDF document and edit password on PDF file. More details are given on this page. C#.NET: Edit PDF Password in ASP.NET.
password protected pdf; pdf security password
Figure 67.  Situation 2B: Application Interoperability with Application-Level Translation and Transport Resolution
If there is no flexibility in recoding the application, then the situation shown in
Figure 67 occurs. Usually multiple protocol layers must be converted, including
the transport protocol. There are fewer solution possibilities in this case, as
shown in Figure 68 on page 109.
108
Introduction to Networking Technologies 
C# PDF Library SDK to view, edit, convert, process PDF file for C#
WinFoms project. Support protecting PDF file by adding password and digital signatures with C# sample code in .NET Class. Feel free
copy protection pdf; add password to pdf online
VB.NET PDF Library SDK to view, edit, convert, process PDF file
program. Support adding protection features to PDF file by adding password, digital signatures and redaction feature. Various of
break a pdf password; pdf password unlock
Figure 68.  Situation 2B: Technology Choices
Both of these solutions can handle the necessary conversions at the upper
levels of the protocol stacks, as well as the transport differences. The
fundamental difference between the two approaches is whether end-to-end
connectivity is required between the applications. Application gateways provide
this end-to-end capability; multi-protocol servers do not. It might be critical for
a database access application to maintain end-to-end connectivity, but perhaps
not for an electronic mail “mailbox” application to do so. The choice of
particular implementation will depend upon what is available in the marketplace
for the desired application type and platforms.
Considerations to be kept in mind as these technologies are evaluated include
the following:
Multi-Protocol Servers
•
Is an end-to-end connection required? Or is it adequate for the server to
provide translation capabilities for various applications?
•
Is this a mission-critical application which should be dependent on a
potential single point of failure?
•
How much traffic can a particular server handle efficiently? How can
additional users be handled?
•
Can additional transport protocols be supported? Can additional
applications be supported?
Application Gateway
•
Does full translation capability exist to communicate with the remote
application, or is just a subset of functions available?
Chapter 3. Typical Customer Situations
109
VB.NET PDF Convert to Jpeg SDK: Convert PDF to JPEG images in vb.
Convert Jpeg to PDF; Merge PDF Files; Split PDF Document; Remove Password from PDF; Change PDF Permission Settings. Able to convert password protected PDF document
pdf open password; convert password protected pdf to excel
C# PDF Convert to HTML SDK: Convert PDF to html files in C#.net
Convert PDF to HTML. |. C#.NET PDF SDK - Convert PDF to HTML in C#.NET. How to Use C# .NET XDoc.PDF SDK to Convert PDF to HTML Webpage in C# .NET Program.
add password to pdf without acrobat; protected pdf
•
Is this a mission-critical application which should be dependent on a
potential single point of failure?
•
How much traffic can a particular gateway handle efficiently? How can
additional users be handled?
•
Can additional transport protocols be supported? Can additional
applications be supported?
110
Introduction to Networking Technologies 
3.2.3 Situation 3 - Network Interconnection
As organizations within a single enterprise need to communicate to start a new
business initiative, or companies merge, the need for existing networks to
interconnect occurs. Interconnection always involves physically connecting two
separate networks, which might also be some distance apart. Also, it assumes
that the same application will be used in both networks for exchanging
information. Thus, two steps are usually involved in network interconnection:
first, addition of the application to the networks (if needed), and second,
establishment of physical connectivity between these networks.
When evaluating the various alternatives available to establish the physical
connectivity, two situations commonly arise. In the first situation, a low-cost,
single gateway between the two networks is desired: this is Situation 3A
(Figure 69). In the second case, an intervening network is placed between the
two networks. This intervening network may be owned by one of the
organizations, or in fact may be owned by a third organization. This intervening
network may use a different transport protocol than the application requires.
This scenario is discussed in Situation 3B (Figure 71 on page 114).
Figure 69.  Situation 3A: Network Interconnection via Direct Connection
For Situation 3A, the interconnection involves the addition of an existing
application in one network to the second network (often referred to as extending
the “reach” of the application). As shown in Figure 69, Appl-A which uses
transport protocol A already exists in Network #1, and now must be added to
Network #2, which currently utilizes transport protocol B. This forces Network #2
to handle the second protocol.
Chapter 3. Typical Customer Situations
111
Although this application addition to Network #2 might initially appear to be
similar to Situation 1, there are several significant differences. In Situation 1, it
was assumed that a single network under the control of a single organization
was involved in the decision to add a new application. The issues become more
complex in this situation, when the two networks are physically separate,
perhaps quite a distance apart, and often under the control of different
organizations.
As shown in Figure 69 on page 111, Network A must directly connect to Network
B. For instance, Network A might be an SNA wide area network with 3745 front
end processors, and Network B might be a token ring network with Novell
Netware and IPX transport protocol - and now the Novell Netware users must
access an SNA application. Multiple issues exist in this type of scenario, such
as how to physically connect the local area network to the wide area network,
and how to integrate the new transport protocol into the LAN users'
environment.
Due to the condition that direct connection is required, with no intervening
network, the following solutions shown in Figure 70 are possible. These are
solutions that can exist in a single gateway configuration. Note that these
solutions span quite a range; from those that focus strictly on the subnetwork
level to solutions that operate at the upper layers.
Figure 70.  Situation 3A: Technology Choices
If the two networks are LANs that are physically located next to each other, then
a local bridge can be considered. A multi-protocol router may also be
considered in this local situation, especially since it may provide additional
filtering capabilities over the bridge.
112
Introduction to Networking Technologies 
For wide area networks, particularly those networks which desire to restrict the
number of transport protocols, encapsulation can be used. Encapsulation will be
performed at an end node, the de-encapsulation at a gateway which physically
connects the two networks. MPTN can similarly be used in a single gateway
configuration, with one end node being the access node. Multi-protocol servers
and a Remote API server can provide the physical connectivity as well as the
application connectivity.
One might also wish to consider where the data is physically located in the
network in deciding among these solutions. For instance, a multi-protocol server
allows the data to be stored in one central facility that all users can access. For
distributed data, remote APIs, encapsulation, and MPTN might be appropriate.
Considerations to be kept in mind as these technologies are evaluated include
the following:
Local Bridges
•
Are the LANs located in close enough proximity for a local bridge to
attach?
•
Is there too much unnecessary traffic to require filtering?
Encapsulation
•
Will this encapsulating software be placed in the end nodes? Or will it
be placed in a separate node, requiring additional hardware?
•
How is the encapsulation actually performed? Are Data Link Control
protocols properly terminated and emulated? Are the transport-level
protocols properly emulated? Is filtering of unnecessary packets
performed?
•
What are the performance characteristics of this encapsulation software?
Is this acceptable?
•
How are the different network addresses handled? What directory
services exist?
•
How expandable is this approach if the network grows and more nodes
are added?
Multi-Protocol Routers
•
Are all needed protocols handled by the router?
•
Are there any Data Link Control-level concerns? Does the router
properly handle these protocols?
•
What happens in congestion situations? Are all protocols equal? Can
the traffic be prioritized?
•
How much filtering is available for each protocol?
MPTN
•
Do MPTN implementations exist for the necessary protocols?
•
If MPTN implementations exist for these protocols, do they exist on the
required operating system platforms in the end nodes? If not, do they
exist for operating system platforms, which could be used as a gateway?
Remote APIs
•
What APIs are supported over which protocols? Does the correct
combination exist?
•
Does this “skinny client” provide enough functionality to satisfy the
application requirements?
Chapter 3. Typical Customer Situations
113
Multi-Protocol Servers
•
Is an end-to-end connection required? Or is it adequate for the server to
provide translation capabilities for various applications?
•
Is this a mission-critical application which should be dependent on a
potential single point of failure?
•
How much traffic can a particular server handle efficiently? How can
additional users be handled?
•
Can additional transport protocols be supported? Can additional
applications be supported?
Figure 71.  Situation 3A: Network Interconnection via a Backbone Network
This second case involves an intermediate network between two existing
networks of a single transport protocol type. The intermediate network, Network
#3 in Figure 71, is often called a backbone  network. The backbone network
might be a high-speed local area network (such as a FDDI network
interconnecting slower-speed local area networks), a public carrier network
(such as a value added packet switch network), or a private wide area network
(such as an SNA network). The backbone network might be controlled by a
different organization than Network #1 and Network #2. In this scenario, it is
assumed that both Network #1 and Network #2 have Appl-A, which utilizes
transport protocol A, but the backbone network might utilize transport protocol B.
For instance, Appl-A might use TCP/IP, but Network #3 might use SNA. Again,
there are physical connectivity problems as well as transport protocol resolution.
Solutions which have double gateway implementations, such as those shown in
Figure 44 on page 66, will work quite well in this situation. Note that these
solutions focus mainly on the subnetworking and transport layers; the upper
application layers are not affected.
114
Introduction to Networking Technologies 
Documents you may be interested
Documents you may be interested