All Pages All Books|
|
||||
|
Introducing the Microsoft .NET Platform • Chapter 1 11
|
||||
|
|
||||
|
For example, today when a user is interacting with a portal site, it appears to them that they are working with one remote server. Most of us know that is normally not the case, at least for a site of any significant size. There are various servers and applications behind the scenes are accessing information on several remote sites, combining it with information from their user database and merging it all into an integrated product that is delivered to the user via their browser.
As useful as these types of applications are, they are all very complex to develop and maintain. Each provider of information has developed different interfaces to access data and processes on their servers. This redundant development is grossly inefficient and for the most part fairly boring, so there has been a great deal of activity around three standards to streamline the process: XML, SOAP, and UDDI. As we discussed earlier, these are used in .NET and also in competing, less well known initiatives from IBM and Sun.
Interoperability with Unmanaged Code
As you can probably guess, unmanaged code is code that isn’t managed by the .NET Common Language Runtime. However, this code is still run by the CLR, it just doesn’t get the advantages that it offers, such as the Common Type System and Automatic Memory Management. You will probably end up using unmanaged code in a couple of different situations:
■ Calling DLL functions There is a lot of functionality locked inside DLLs today. Not every company is going to rush to deliver a .NET component version of their products, so if you need to interface with them, you’ll be calling unmanaged code.
■ Using COM components This is likely to be for pretty much the same reasons you might be required to call DLL functions.
■ Calling .NET services from COM components Although this sounds a little odd, it is possible. A COM client can be made to call a .NET component as though it was a COM server.
Here’s a little more information on the COM interoperability issue. Microsoft didn’t want to force companies to abandon their existing COM components; especially because many of Microsoft’s own products are COM-based today. COM components interoperate with the .NET runtime through an interop layer that handles all the work required when translating messages that pass back and forth between the managed runtime and the COM components operating as unmanaged code.
|
||||
|
|
||||
|
|
|
|||
|
|
||||
All Pages All Books