.Net

1
.Net

• Interoperability System Level Considerations

2
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

3
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.

4
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.

5
Run Time Callable Wrappers
Unmanaged Code
Managed Code

Interfaces
COM
RTW
Client
Common Language Run Time
6
Com Callable Wrapper
Unmanaged Code
Managed Code

Interface
COM Client
CCW
.Net Object
Common Language Run Time
7
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.

8
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.

9
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.

10
Managed-Non COM basedDLL 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.

11
Managed-Non COM basedDLL 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

12
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

13
ADO.NET
Managed Code

Client
Data Adapter
RBMS
CMD Process
Common Run Time language
14
ADO.NETData Adapters
Managed Code

SQL Server
SQL
Client
OLE
OLE Driver
ODBC
ODBC Drivers
15
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.

16
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

17
ASP.NET
Html Etc.

Client
Page
IIS
ADO
Controls
These could be .NET or COM
Common Language RunTime
18
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

19
ASPBasic HTML page.

• lthtmlgt
• ltscript runatserver language vbgt
• Sub ShowNumber()
• Dim I as Integer
• For I 0 to 5
• Response.Write(I)
• Next I
• End Sub
• lt/scriptgt
• Date Time lt Now() gt ltbrgt
• Some Numbers lt ShowNumber() gt
• lt\htmlgt

20
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(ltbrgt)
• Response.Write (Some Numbers )
• Show Numbers()
• End Sub
• End Class

21
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.

22
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.

23
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)

24
An Example.

Internet
Portal Server
Client
IntraNet
Local Applications
Specific Service
25
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

26
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

27
Proxy Structure

WEB Service
Portal Server Acting as Web Service Client
Proxy Stub
28
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)