.Net

acceptableseashoreSecurity

Nov 5, 2013 (3 years and 9 months ago)

58 views

.Net

Interoperability & System Level
Considerations

Interoperability


Legacy leaves System Level Interoperability as
a major factor


Mechanisms have to exist at System Level for
access from within the Managed Environment
to Legacy Objects

Problems


Type Translation


Within the managed environment we are in a CTS
derived type structure.


Not consistent with the type structure normally associated
with older Windows Applications or Network Interactive
applications


We must therefore consider system level
interoperability and marshalling across this
boundary.


COM Solutions



Two options exist



Run Time callable Wrappers


Access COM objects from the managed environment


COM callable Wrapper


Allow COM Containers to access .NET objects as if they
are outside the managed environment.

Run Time Callable Wrappers



Common Language Run Time

Unmanaged Code

Managed Code

COM

Interfaces

RTW

Client

Com Callable Wrapper



Common Language Run Time

Unmanaged Code

Managed Code

COM

Client

CCW

Interface

.Net

Object

Making The RTW


Fairly automated process


The Type Library was the pseudo Meta Data for
‘COM’


IDL used to describe the Interfaces.


Registry Entries location etc.


Create from this source information a new .NET
compliant Assembly including the required stub
code and XML that .NET can interface.

Making the CCW


Again automated process


In this case the type library needs to be created from
the XML in the .NET assembly


Need to create the IDL and from this a suitable type
library.


Suitable COM object entries need to established within
the Registry so that the COM clients (Containers) can
find the entries they would expect from an older COM
object.

COM


Managed Code

Call Boundary


Marshalling the Data


A degradation of performance is a natural
consequence of working between a managed and
unmanaged code boundary.


It is generally accepted that at the boundary as much data
mapping (marshalling) as possible is carried out at each
interface call, failure to do this and being reliant on
multiple calls will undoubtedly lead to a far larger
marshalling overhead.

Managed
-
Non COM based

DLL interface


Although a large proportion of the platform
dependant WIN32 API is wrapped within the
.NET Framework Class library structure, some
is not!


Obviously a mechanism to access these unavailable
feature needs to be present.

Managed
-
Non COM based

DLL interface


Platform Invoke.


This is the service .NET offers.


As was the case in VB6 etc., to use non managed DLL
interfaces then one must fully quantify the location and
prototype of the feature selected.


VB.NET uses ‘Declare’


C# uses ‘Dllimport’


Once specified


Marshalling is automatic but care must be taken to map the CTS
to the required Type declarations within the API

ADO.NET


This must be considered as part of the
Interoperability service


It is a system level problem to grant any application
access to a DBMS



.NET has addressed the problem by looking at
the older ADO objects and redefining these into
a coherent object solution

ADO.NET



Client

Managed Code

Common Run Time language

Data Adapter

CMD Process

RBMS

ADO.NET

Data Adapters



Managed Code

Client

SQL

OLE

ODBC

SQL Server

OLE Driver

ODBC Drivers

ADO.NET


It may seem strange that three adapter have
been define


SQL this is simple for Microsoft benefit


OLE this allows all DBMS systems local to the app
to be supported by unique OLE drivers.


ODBC this allows remote access to DBMS systems


Note SQL adapter has inbuilt ODBC capabilities.

ASP.NET


Again the changes to the ASP technology is
important from a systems level view point.



ASP has changed its total structure with regard to
invocation, therefore ASP using interoperability
etc., posses system level constraints which
previously did not need consideration

ASP.NET



Client

IIS

Page

Html Etc.

Controls

ADO

These could be .NET


or COM

Common Language RunTime

ASP


The Clever Bit and the bit that requires System
level interfacing, is the translation from a WEB
page to CLR compliant language and interface
to the Class Library framework



The easy way to demonstrate the basis of this is
to look at a very simple example

ASP

Basic HTML page.


<html>

<script runat=“server” language = “vb”>

Sub ShowNumber()

Dim I as Integer

For I = 0 to 5


Response.Write(I)

Next I

End Sub

</script>

Date & Time : <% = Now() %> <br>

Some Numbers : <% ShowNumber() %>

<
\
html>

ASP

.NET Translated Class

Class Example


Inherits System.WEB.UI.page

Sub ShowNumber()

Dim I as Integer

For I = 0 to 5


Response.Write(I)

Next I

End Sub

Sub Render()


Response.Write(“Date & Time: “)


Response.Write(Now())


Response.Write(“<br>”)


Response.Write (“Some Numbers : “)


Show Numbers()

End Sub

End Class

The Execution Process


Conventional ASP the page was executed as it
was parsed by the server or the browser



You got strange recursive effects taking place



This was problematic for the system developer
requiring blank page loads etc., between
responses etc.

The New process


When client requests the page


Assembly of the page is accessed and JIT compiled


Events are generated


On Load for example



When all events for the page have been handled
then the class object for the page is released and the
auto garbage collection will remove the class object
at some time in the future.

Services


Unlike ASP services that run on the server and
have WWW pages associated with them


WEB Services are generally derived without a GUI
page associated



So we can view these as programmatic objects that
can be accessed via simple protocols (http)

An Example.



Portal Server

Internet

Client

Specific

Service

Local


Applications

IntraNet

Example


Here we have


Client browses to a Portal Serer


Selects a specific service and the Portal activates the
WEB service to instigate a interrogation of this specific
service


Specific Service again uses WEB services this time on an
Intranet to access specific applications.


With such a structure the response to the client visa the
intranet is fully structured, generated programmatically
from the an Application that is not directly accessible by
the client on the WWW

The Client
-
Server problems for
programmatic WEB Services


Requires Proxy techniques for the client
application to satisfy the Objects
Instance
references that will occur when the actual
connection is made.


Needs to have asynchronous (non block
facilities whilst the response is being generated)


Otherwise the WEB service will be blocked for
service to any other WWW client

Proxy Structure



Portal Server

Acting as

Web Service Client

Proxy

Stub

WEB

Service

Conclusions


Enterprise or System level solutions require


Consideration of the Managed / UnManaged code
Boundary


Objects for manipulation of Interoperability with
DBMS systems need careful consideration


Web Services move the concept of Middleware
beyond simple active objects to invoking full
applications using simple protocols. (http)