Saturday, June 29, 2013
What is .NET?
you’ve
probably heard some of the buzz surrounding the Microsoft .net
framework(.net).with that buzz have come announcements from a wide variety of
language vendors indicating support for the new initiative. The question arises:
Why is
Microsoft interested in having so many languages target the new Environment?
The
answer lies in recognizing that most businesses do not have the luxury of
rewriting their large code base every time they want to extend the use of their
existing applications.
Microsoft®
.NET is a set of Microsoft software technologies for connecting your world of
information, people, systems, and devices. It enables an unprecedented level of
software integration through the
use of XML Web services: small, discrete, building-block applications that
connect to each other—as well as to other, larger applications—via the
Internet. .NET connected software delivers what developers need to create XML
Web services and stitch them together. The benefit to individuals is seamless,
compelling experiences with information sharing.
Understanding .NET:
Microsoft .NET
expands opportunities to act on data and communicate anywhere, anytime, on any
device. .NET connected software uses a distributed computing model and builds
on open standards like XML to connect PCs and other smart devices. Understand
the basics.
·
What
are XML Web Services?
·
What
.NET Means for Business
Product Information:
.NET
connected software from Microsoft includes a comprehensive family of products—clients that power smart devices,
services, servers, and tools—designed to support XML and incorporate Internet
industry standards. More....
·
Microsoft
Servers and .NET
·
Microsoft
Visual Studio® .NET
·
.NET
Framework
Using .NET:
At its
core, Microsoft .NET is about making technology work for people, instead of
forcing individuals to adapt to the limitations of their computers. More ...
·
What
.NET Means for Business
·
XML
Web Services Case Studies
Developing with .NET:
Microsoft
Visual Studio .NET and Microsoft .NET Framework not only change the way
applications can be developed but also make it possible to create new kinds of
applications. More ...
·
.NET
and Security
XML Web Services Basics:
Summary: An overview of the
value of XML Web services for developers, with introductions to SOAP, WSDL, and
UDDI. (6 printed pages)
Contents:
·
What
Is an XML Web Service?
·
SOAP
·
WSDL
·
UDDI
What
Is an XML Web Service?
XML Web
services are the fundamental building blocks in the move to Distributed computing on the Internet. Open
standards and the focus on communication and collaboration among people and
applications have created an environment where XML Web services are becoming
the platform for application integration. Applications are constructed using
multiple XML Web services from various sources that work together regardless of
where they reside or how they were implemented.
There
are probably as many definitions of XML Web Service as there are companies building them, but almost
all definitions have these things in common:
XML Web Services expose useful
functionality to Web users through a standard
Web protocol.In most cases, the protocol used is soap.
XML Web
services provide a way to describe their interfaces in enough detail to allow a
user to build a client application to talk to them. This description is usually
provided in an XML document called a Web Services Description Language (WSDL)
document.
XML Web
services are registered so that potential users can find them easily. This is done
with Universal Discovery Description and Integration (UDDI).
I'll
cover all three of these technologies in this article but first I want to
explain why you should care about XML Web services. One of the primary
advantages of the XML Web services architecture is that it allows programs
written in different languages on different platforms to communicate with each other
in a standards-based way. Those of you who have been around the industry a
while are now saying, "Wait a minute! Didn't I hear those same promises
from CORBA and before that DCE? How is this any different?" The first
difference is that SOAP is significantly
less complex than earlier approaches, so the barrier to entry for a
standards-compliant SOAP implementation is significantly lower. Paul Kulchenko
maintains a list of SOAP implementations at:
http://www.soapware.org/directory/4/implementations
which at last
count contained 79
entries. You'll find SOAP implementations from most of the big software
companies, as you would expect, but you will also find many implementations
that are built and maintained by a single developer. The other significant
advantage that XML Web services have over previous efforts is that they work
with standard Web protocols—XML, HTTP and TCP/IP. A significant number of
companies already have a Web infrastructure, and people with knowledge and
experience in maintaining it, so again, the
cost of entry for XML Web services is significantly less than previous
technologies.
We've defined an XML Web service as
a software service exposed on the Web through SOAP, described with a WSDL file
and registered in UDDI. The next logical question is. "What can I do with
XML Web services?" The first XML Web services tended to be information sources
that you could easily incorporate into applications—stock quotes, weather
forecasts, sports scores etc. It's easy to imagine a whole class of
applications that could be built to analyze and aggregate the information you
care about and present it to you in a variety of ways; for example, you might
have a Microsoft® Excel spreadsheet that summarizes your whole financial
picture—stocks, 401K, bank accounts, loans, etc. If this information is
available through XML Web services, Excel can update it continuously. Some of
this information will be free and some might require a subscription to the service.
Most of this information is available now on the Web, but XML Web services will
make programmatic access to it easier and more reliable.
Exposing
existing applications as XML Web services will allow users to build new, more powerful
applications that use XML Web services as building blocks. For example, a user
might develop a purchasing application to automatically obtain price
information from a variety of vendors, allow the user to select a vendor,
submit the order and then track the shipment until it is received. The vendor
application, in addition to exposing its services on the Web, might in turn use
XML Web services to check the customer's credit, Charge the customer's account
and set up the shipment with a shipping company.
In the
future, some of the most interesting XML Web services will support applications
that use the Web to do things that can't be done today. For example, one of the
services that the Microsoft .NET My Services project will support is a calendar
service. If your dentist and mechanic exposed their calendars through this XML
Web service, you could schedule appointments with them on line or they could
schedule appointments for cleaning and routine maintenance directly in your
calendar if you like. With a little imagination, you can envision hundreds of
applications that can be built once you have the ability to program the Web.
For more
information on XML Web services and the applications they will help you build, please
see the MSDN Web services home page.
SOAP
Soap is
the communications protocol for XML Web services. When SOAP is described as a
communications protocol, most people think of DCOM or CORBA and start asking
things like, "How does SOAP do object activation?" or "What
naming service does SOAP use?" While a SOAP implementation will probably
include these things, the SOAP standard doesn't specify them. SOAP is a
specification that defines the XML format for messages—and that's about it for
the required parts of the spec. If you have a well-formed XML fragment enclosed
in a couple of SOAP elements, you have a SOAP message. Simple isn't it?
There
are other parts of the SOAP specification that describe how to represent
program data as XML and how to use SOAP to do Remote Procedure Calls. These
optional parts of the specification are used to implement RPC-style
applications where a SOAP message containing a callable function, and the
parameters to pass to the function, is sent from the client, and the server
returns a message with the results of the executed function.
Most
current implementations of SOAP support RPC applications because programmers
who are used to doing COM or CORBA applications understand the RPC style. SOAP
also supports document style applications where the SOAP message is just a
wrapper around an XML document. Document-style SOAP applications are very
flexible and many new XML Web services take advantage of this flexibility to
build services that would be difficult to implement using RPC.
The last
optional part of the SOAP specification defines what an HTTP message that
contains a SOAP message looks like. This HTTP binding is important because HTTP
is supported by almost all current OS's (and many not-so-current OS's). The
HTTP binding is optional, but almost all SOAP implementations support it
because it's the only standardized protocol for SOAP. For this reason, there's
a common misconception that SOAP requires HTTP. Some implementations support
MSMQ, MQ Series, SMTP, or TCP/IP transports, but almost all current XML Web
services use HTTP because it is ubiquitous. Since HTTP is a core protocol of
the Web, most organizations have a network infrastructure that supports HTTP
and people who understand how to manage it already. The security,monitoring,
and load-balancing infrastructure for HTTP are readily available today.
A major
source of confusion when getting started with SOAP is the difference between
the SOAP specification and the many implementations of the SOAP specification.
Most people who use SOAP don't write SOAP messages directly but use a SOAP toolkit
to create and parse the SOAP messages. These toolkits generally translate
function calls from some kind of language to a SOAP message. For example, the
Microsoft SOAP Toolkit 2.0 translates COM function calls to SOAP and the Apache
Toolkit translates JAVA function calls to SOAP. The types of function calls and
the datatypes of the parameters supported vary with each SOAP implementation so
a function that works with one toolkit may not work with another. This isn't a
limitation of SOAP but rather of the particular implementation you are using.
By far
the most compelling feature of SOAP is that it has been implemented on many
different hardware and software platforms. This means that SOAP can be used to
link disparate systems within and without your organization. Many attempts have
been made in the past to come up with a common communications protocol that
could be used for systems integration, but none of them have had the widespread
adoption that SOAP has. Why is this? Because SOAP is much smaller and simpler
to implement than many of the previous protocols. DCE and CORBA for example
took years to implement, so only a few implementations were ever released.
SOAP, however, can use existing XML Parsers and HTTP libraries to do most of
the hard work, so a SOAP implementation can be completed in a matter of months.
This is why there are more than 70 SOAP implementations available.
SOAP
obviously doesn't do everything that DCE or CORBA do, but the lack of
complexity in exchange for features is what makes SOAP so readily available.
The
ubiquity of HTTP and the simplicity of SOAP make them an ideal basis for
implementing XML Web services that can be called from almost any environment.
For more information on SOAP, see the MSDN SOAP home page.
What
about Security?
One of
the first questions newcomers to SOAP ask is how does SOAP deal with
security.Early in its development, SOAP was seen as an HTTP-based protocol so
the assumption was made that HTTP security would be adequate for SOAP. After
all, there are thousands of Web applications running today using HTTP security
so surely this is adequate for SOAP. For this reason, the current SOAP standard
assumes security is a transport issue and is silent on security issues.
When
SOAP expanded to become a more general-purpose protocol running on top of a
number of transports, security became a bigger issue. For example, HTTP
provides several ways to authenticate which user is making a SOAP call, but how
does that identity get propagated when the message is routed from HTTP to an
SMTP transport? SOAP was designed as a building-block protocol, so fortunately,
there are already specifications in the works to build on SOAP to provide
additional security features for Web services. The WS-Security specification
defines a complete encryption system.
WSDL:
WSDL
(often pronounced whiz-dull) stands for Web Services Description Language. For
our purposes, we can say that a WSDL file is an XML document that describes a
set of SOAP messages and how the messages are exchanged. In other words, WSDL
is to SOAP what IDL is to CORBA or COM. Since WSDL is XML, it is readable and
editable but in most cases, it is generated and consumed by software.
To see
the value of WSDL, imagine you want to start calling a SOAP method provided by one
of your business partners. You could ask him for some sample SOAP messages and
write your application to produce and consume messages that look like the
samples, but this can be error-prone. For example, you might see a customer ID
of 2837 and assume it's an integer when in fact it's a string. WSDL specifies
what a request message must contain and what the response message will look
like in unambiguous notation.
The
notation that a WSDL file uses to describe message formats is based on the XML
Schema standard which means it is both programming-language neutral and
standards-based which makes it suitable for describing XML Web services
interfaces that are accessible from a wide variety of platforms and programming
languages. In addition to describing message contents, WSDL defines where the
service is available and what communications protocol is used to talk to the
service. This means that the WSDL file defines everything required to write a
program to work with an XML Web service. There are several tools available to read
a WSDL file and generate the code required to communicate with an XML Web
service.
Some of
the most capable of these tools are in Microsoft Visual Studio® .NET. Many current SOAP toolkits include tools
to generate WSDL files from existing program interfaces,
but there are few tools for writing WSDL directly, and tool support for WSDL isn't
as complete as it should be. It shouldn't be long before tools to author WSDL files,
and then generate proxies and stubs much like COM IDL tools, will be part of most
SOAP implementations. At that point, WSDL will become the preferred way to
author SOAP interfaces for XML Web services.
An
excellent description of WSDL is available, and you can find the WSDL
specification at
http://www.w3.org/TR/wsdl.
UDDI:
Universal Discovery Description
and Integration is the yellow pages of Web services. As with traditional yellow
pages, you can search for a company that offers the services you need, read
about the service offered and contact someone for more information. You can,of
course, offer a Web service without registering it in UDDI, just as you can
open a business in your basement and rely on word-of-mouth advertising but if
you want to reach a significant market, you need UDDI so your customers can
find you.
A UDDI
directory entry is an XML file that describes a business and the services it offers.
There are three parts to an entry in the UDDI directory. The "white
pages" describe the company offering the service: name, address, contacts,
etc. The "yellow pages" include industrial categories based on
standard taxonomies such as the North American Industry Classification System
and the Standard Industrial Classification. The "green pages"
describe the interface to the service in enough detail for someone to write an
application to use the Web service. The way services are defined is through a
UDDI document called a Type Model or tModel. In many cases, the tModel contains
a WSDL file that describes a SOAP interface to an XML Web service, but the
tModel is flexible enough to describe almost any kind of service.
The UDDI
directory also includes several ways to search for the services you need to build
your applications. For example, you can search for providers of a service in a specified
geographic location or for business of a specified type. The UDDI directory will
then supply information, contacts, links, and technical data to allow you to evaluate
which services meet your requirements.
UDDI
allows you to find businesses you might want to obtain Web services from. What
if you already know whom you want to do business with but you don't know what
services are offered? The WS-Inspection specification allows you to browse
through a collection of XML Web services offered on a specific server to find
which ones might meet your needs. More information about UDDI is available at
http://www.uddi.org/about.html.
What .NET Means for Business:
By using
the Internet to enable software applications to more easily work together,
Microsoft® .NET promises easier integration within and between businesses,
while creating opportunities to more meaningfully connect with consumers. With
.NET software and services, businesses can realize improvements in the time and
cost associated with developing and maintaining their business applications, as
well as benefitting from empowering employees with the ability to act on vital
information anywhere, from any smart device.
·
.NET
will deliver best of breed integration for businesses.
·
Exposing
XML Web services increases potential reach and exposure, creating new business
opportunities.
·
.NET
promises substantial savings in development costs, as well as creating new
revenue streams, through the use of XML Web services. Web Sites and Web
Services For businesses to truly harness the power of the Internet, Web sites
must evolve. They must learn to interact with one another as well as with
existing systems and applications. XML Web services represent the evolution of
the Web site.
.NET and Security:
Security
and privacy are a central part of creating and delivering compelling user experiences.
Distributing computing power across numerous systems—both inside and outside the
walls of your home or company—creates new types of challenges.
The
Microsoft® .NET platform is built from the ground up with security in mind. Coupled
with good operational practices by individuals and administrators, it provides
the basis for a computing experience that puts users in control of their
personal and business information.
The .NET
Framework, the programming engine at the heart of the .NET platform, provides
the means to secure both client and server machines through its core security
features. Developers can focus on application logic because security is handled
transparently at the core level by the common language runtime. Yet developers
can use and extend the security model at any time.
.NET Framework:
1.
Common Language
Runtime Architecture:
Microsoft .NET
Framework provides a Common Language Runtime (CLR) that manages the execution of source code after being compiled into
Microsoft intermediate language (MSIL), OptIL, or native machine code. All code based on MSIL or OptIL executes as managed
code; that is code that runs under a "contract of cooperation"
with the .NET Framework. The.NET
Framework provides services such as memory management, cross language
integration, exception handling, code access security, and automatic lifetime
control of objects.
A key feature of CLR
is its ability to provide software isolation
of programs running within a single address space. It does this by enforcing typesafe access to
all areas of memory when running typesafe managed code. Some compilers generate MSIL that is not only
typesafe but whose type safety can be proven by simply examining the MSIL. This process, verification,
allows servers to quickly examine user programs written in MSIL and only run
those that it can demonstrate will not make unsafe memory references. This independent verification is critical to
truly scalable servers that execute user-defined programs (scripts).
The
CLR provides the following services:
·
Code
management
·
Software
memory isolation
·
Verification
of the type safety of MSIL
·
Conversion
of MSIL to native code
·
Loading
and execution of managed code (MSIL or native)
·
Accessing
metadata (enhanced type information)
·
Managing
memory for managed objects
·
Insertion
and execution of security checks
·
Handling
exceptions, including cross-language exceptions
·
Interoperation
between .NET Framework objects and COM objects
·
Automation
of object layout for late binding
·
Supporting
developer services (profiling, debugging, etc.)
One of the most
important functions of the CLR is on-the-fly conversion
of MSIL (or OptIL) to native code. Source code compilers generate MSIL (or
OptIL), and JIT compilers convert that
MSIL to native code for specific machine architectures. As long as a simple set of rules is followed
by the MSIL generator, the same MSIL code will run on any architecture that
supports the .NET Framework. Because the
conversion from MSIL to native code occurs on the target machine, the generated
native code can take advantage of hardware-specific optimizations. Other significant CLR functions include class
loading, verification, and support for security checks.
1.1 MSIL and OptIL:
MSIL is a
stack-based set of instructions designed to be easily generated from source
code by compilers and other tools.
Several kinds of instructions are provided, including instructions for
arithmetic and logical operations, control flow, direct memory access, exception
handling, and method invocation.
It can also be
converted efficiently into native code.
The design of MSIL allows this process to produce optimized native code
at reasonable cost. The design of MSIL allows programs that are not typesafe to
be expressed, since this is essential for support of some common programming
languages. At the same time, by
following a simple set of rules, it is possible to generate MSIL programs that
are not only typesafe but can easily be proven to be so (see the Verification section
for more information about type safety and verification).
OptIL is
a subset of MSIL
that can be generated by optimizing compiler front ends. OptIL contains
embedded annotations, which are MSIL instructions that supply control flow and
register allocation information. Since OptIL is a subset of MSIL, any component
that can execute or analyze MSIL can also analyze or execute OptIL (ignoring
the embedded annotations if necessary).
The OptJIT compiler (to be shipped in a future release), however, uses the
embedded information to rapidly produce optimized native code. The correctness
of this native code depends on the annotations, so they are subject to
verification. OptIL is useful in
situations where limited time and memory resources
are available during the conversion to native code (ie at JIT time), yet the
native code produced must meet high performance standards.
1.2 JIT Compilation:
The CLR provides
three JIT compilers for converting MSIL to native code:
EconoJIT, JIT, and OptJIT. Each JIT
compiler has been designed to meet specific goals with respect to performance
and resource usage. The performance
characteristics are summarized in Error!
Reference source not found..
Because of the low overhead of the
EconoJIT compiler, as well as the ease with which it can be ported to new
architectures, the .NET Framework does not include an interpreter for
MSIL. (EconoJIT is so named because it
performs the same task as the full JIT compiler, but using less computer resources. As a trade-off, the quality of the generated
code is not so high).
JIT Compiler
|
Input Language
|
JIT Compiler Overhead
|
Compilation Speed
|
Quality of Output
|
EconoJIT
|
MSIL (incl. OptIL)
|
Very Small
|
Very Fast
|
Low
|
JIT
|
MSIL (incl. OptIL)
|
Medium to Large
|
Moderate
|
High
|
OptJIT
(not in V1) |
OptIL only
|
Small
|
Fast
|
High
|
Figure 1: Performance Characteristics
of .NET Framework JIT Compilers
1.3 Class Loading:
The CLR’s class
loader loads the implementation of a class,
expressed in MSIL, OptIL or native code, into memory, checks
that it is consistent with assumption made about it by other previously loaded
classes, and prepares it for execution. To
accomplish this task, the class loader ensures that certain information is
known, including the amount and the shape of the space that instances of the
type require. In addition, the class
loader determines whether references made by the loaded type are available at
runtime and whether references to the loaded type are consistent.
The class loader
checks for certain consistency requirements that are vital to the .NET
Framework security enforcement mechanism. These checks constitute a minimal,
mandatory, verification process that precedes the MSIL verification, which is
more rigorous (and optional). In addition, the class loader supports security enforcement by providing some of
the credentials required for validating code identity. For more details, see the Technical Review of the CLR Virtual Object System_cor_Virtual_Object_System specification.
CLR allows only one class
loader, its own. The .NET Framework does
not support user-written class loaders.
1.4 Verification:
Typesafe programs reference only memory that has been allocated for their use,
and they access objects only through their public interfaces. These two
restrictions allow objects to safely share a single
address space, and they guarantee that security checks provided by the
objects’ interfaces are not circumvented. Code access security, the CLR’s
security mechanism, can effectively protect code from unauthorized access only
if there is a way to verify that the code is typesafe.
To meet this need,
the CLR uses the information in type signatures to help determine whether MSIL
code is typesafe. It checks to see that
metadata is well-formed, and it performs control flow analyses to ensure that
certain structural and behavioral conditions are met. The runtime declares that
a program is successfully verified only if it is typesafe.
Used in conjunction
with the strong typing of metadata and MSIL, such checking can ensure the type
safety of programs written in MSIL. The
.NET Framework requires code to be so checked before
it is run, unless a specific (administratively controlled) security
check determines that the code can be fully trusted.
1.5 Security Checks:
The CLR is involved
in many aspects of the .NET Framework’s security mechanism. In addition to the verification process
required by code access security, the CLR provides support that enables both
declarative and imperative security checks to occur.
Declarative
security checks
take place automatically whenever a method is called. The permissions that are
required in order to access the method are stored in the component’s metadata.
At run time, calls to methods that are marked as requiring specific
permissions are intercepted to determine whether callers have the required
permissions. A stack walk is sometimes
necessary to determine whether each caller in the call chain also has the required
permissions.
Imperative
security checks
occur when security functions, such as checking a code access permission, or
asserting the right to use a specified permission, are invoked from within the
code being protected. The CLR supports
this type of security check by providing trusted methods that enable code
identity to be determined and allow permissions to be located and stored in the
stack. In addition, the CLR gives the security engine access to administrative information
about security requirements.
1.6 Profiling and Debugging:
The CLR provides the
ability to both debug (observe and modify the behavior) and profile (measure
resource utilization) of running programs.
It does this by providing three underlying services, described in detail
in the Debugging Specifications and the Profiling Specification. Both profiling and debugging depend on
information produced by the source language compiler and updated by the JIT
compiler.
The CLR provides an
API for debugging that handles registration for and notification of events in
the running program. This allows a
debugger to control execution of a program, including setting and handling
breakpoints, intercepting exceptions, modifying control flow, and examining or
modifying program state (both code and data).
The CLR also
provides an API for use by tools that do program profiling. The API supports profiling of managed native
code (e.g. the output of a JITter) both with and without inserting specific
profiling probes into the code.
1.7 Interoperation with Unmanaged Code:
The CLR also
provides for two-way transitions between managed and unmanaged code. This includes interoperation with existing
COM clients and services (known as “COM Interop”) as well as previously
compiled native DLLs (known as “platform invoke”). Where necessary because of data format or
other differences, the CLR supplies marshaling procedures that copy and/or
reformat information across the boundary.
2. Virtual
Execution System:
By providing
services such as class loading, verification, JIT compilation, and code
management, the CLR creates an environment for code execution called the
Virtual Execution System. Figure 2 shows the major elements of the CLR
highlighted in gray, and it indicates with arrows the various paths that can be
taken through this execution environment. In most cases, source code is
compiled into MSIL, the MSIL is loaded, compiled to native code on-the-fly
using one of the JIT compilers, and executed. Note that for trusted code,
verification can be omitted.
The CLR's metadata engine enables the source code compiler to
place metadata in the PE file along with the
generated MSIL or OptIL. (“PE” stands
for Portable Executable, the format used for executable (EXE) and dynamically
linked library (DLL) files). During loading and execution, this metadata provides information needed for
registration, debugging, memory management, and security. Also indicated in the diagram is the fact
that classes from the .NET Framework class library can be loaded by the class loader along with MSIL, OptIL, or native code.
Another execution
path that can be chosen involves pre-compilation to native code using a backend compiler. This option might be chosen if
compiling code at run-time (that’s to say, JIT compiling) is unacceptable due
to performance requirements. As indicated in the diagram, precompiled native
code bypasses verification and JIT compilation. Because precompiled native code
is not verified, it must be considered fully trusted code in order to execute.
Conclusion:
Microsoft has taken the chance
of connecting your world of information, people, systems, and devices. It is
still in its infancy, and will emerge to be a cyber super power dominating
existing frameworks and takes Microsoft towards the winning post providing the
user’s utmost flexibility and efficacy.
