How to Create RMI System

How to Create RMI System

How to create an RMI system
In this article, I lead you through the process of creating a very simple RMI system. (This example was inspired by the RMI demo in Orfali and Harkey's book on CORBA; I thought it was still too complicated, so I've taken the simplification a bit further). I've tried to make this example as bare-bones as possible in order to keep the focus on the steps needed to make an RMI program work. I've also tried to avoid skipping any steps that might throw a first-time user, and have tried to ensure that all steps are performed in the proper order (there are a couple of steps in which order matters). That being said, let's do some RMI!

Steps to creation of an RMI system:


The short version


1) Create an interface. (in this case, the interface is myRMIInterface.java).
2) Create a class that implements the interface. (in this case, myRMIImpl.java).
3) Create a server that creates an instance of this class
4) Create a client that connects to the server object using Naming.lookup()
5) Compile these classes.
6) Run the RMI interface compiler on the .class file of the implementation
class (in this case, you'd say "rmic myRMIImpl").
7) Start the RMI registry (on Windows NT/95, say "start rmiregistry").
8) Start the server class ("start java myRMIServer").
9) Run the client program ("java myRMIClient").

The long version
Create an interface
An interface is similar to a pure virtual class in C++; it defines the methods (and the arguments to the methods) that will be available in a class that implements it; however, it doesn't actually implement any of the methods.
The interface I created for this example is myRMIInterface.java. It contains only one method; the method takes no arguments and returns an object of type java.util.Date. Note 2 things about this interface: 1) it extends the java.rmi.Remote interface (all interfaces used in RMI must do this). 2) the method throws a java.rmi.RemoteException (every method in a remote object's interface must specify this exception in its "throws" clause; this exception is a superclass of all RMI exceptions that can be thrown. See the JDK 1.1 final docs (in the java.rmi section) for a complete list of exceptions that can be thrown.

Create a class that implements the interface
In this example, the implementation is found in myRMIImpl.java. This class must extend java.rmi.UnicastRemoteObject and must implement the interface you created in step 1. In my example, the only method that needs to be implemented is getDate(), which returns the current date and time on the system. Note 2 things about the constructor: 1) the call to super(). 2) the call to Naming.rebind(name, this). This call informs the RMI registry that this object is available with the name given in "String name". Other than that, this object simply implements all the methods declared in the interface.

Create a server that creates an instance of the "impl" class
In this example, the server class is myRMIServer.java. In this case, the server is pretty simple. It does 2 things: 1) Installs a new RMISecurityManager (Note that RMI uses a different security manager from the security manager used for applets). 2) Creates an instance of the myRMIImpl class, and gives it the name "myRMIImplInstance". The myRMIImpl object takes care of registering the object with the RMI registry. After this code is run, the object will be available to remote clients as "rmi://
Create a client that connects to the server object using Naming.lookup().
In this example, the client class is myRMIClient.java. The client first installs a new RMI Security Manager (see previous step), then uses the static method Naming.lookup() to get a reference to the remote object. Note that the client is using the interface to hold the reference and make method calls. You should make sure you've created your interface before you try to build the client, or you'll get "class not found" errors when you try to compile your client.

Compile these classes
Just do "javac *.java". Piece of cake. :-)

Run the RMI interface compiler on your implementation class.
This step generates some additional Java classes. They're stubs and skeletons used by RMI; you don't have to worro about what's in them. Note: You only need to run rmic on the class that implements your RMI interface. In this case, you'd do "rmic myRMIImpl". Also note that the rmic compiler runs on a .class file, not a .java file.

Start the RMI registry
OK. You're done with development at this point; you've built all the code you need to run this example. Now you're setting up the environment so that you can run it. rmiregistry is a program that comes with the JDK 1.1 final; you can find it in the "bin" directory of your JDK installation. Under Windows 95 or NT, you can simply say "start rmiregistry" on the command line, which will cause the RMI registry to be started in its own DOS window. The RMI registry must be started before you can start your server.

Start your RMI server program
Under Windows 95 or NT, say "start java myRMIServer" on the command line. This starts the server running. As we discussed earlier, the server then creates an instance of myRMIImpl and makes it known to the RMI server as "myRMIImplInstance".

Run your client program
Say "java myRMIClient". The program will ask the RMI registry for a reference to "myRMIImplInstance". After it has this reference, the client can invoke any methods declared in the myRMIInterface interface as if the object were a local object.



Problems that you may run into


problem: You get a "class not found" error when running rmic
solution: Add the current directory to your classpath.

problem: You get the following error when running the client


Exception occured: java.rmi.UnmarshalException: Return value class not found; nested exception is:
java.lang.ClassNotFoundException: myRMIImpl_Stub


solution: The file myRMIImpl_Stub.class must be deployed with your client application (that is, you must place it somewhere in the classpath of the client machine; If you were using an applet as a client, you would place it in the directory specified in the CODEBASE parameter to achieve the same effect).

problem: You get the following error when running the client


C:\test3>java myRMIClient 127.0.0.1
Exception occured: java.security.AccessControlException: access denied (java.net
.SocketPermission 127.0.0.1:1099 connect,resolve)

or the following when running the server
C:\test3>java myRMIServer
Exception occurred: java.security.AccessControlException: access denied (java.ne
t.SocketPermission 127.0.0.1:1099 connect,resolve)


solution: I experienced this problem under Java2 with the default security policy in place. You'll need to modify your security policy to allow these activities to take place. A full writeup on this is available at The Sun RMI tutorial page.
In summary, you'll need to do the following:
Create a new security policy file. See your JDK docs or the links referenced from the Sun RMI tutorial for more information on this.
When you run the client or the server, pass the location of your new security policy file in as an argument. This allows you to run under a new policy without having to modify your system policy files. Here is a .policy file that grants all permissions to everybody. DO NOT install this policy file in a production system. However, you can use it in trivial testing. You can then run the server with the command line
java -Djava.security.policy=c:\test3\wideopen.policy myRMIServer
or the client with
java -Djava.security.policy=c:\test3\wideopen.policy myRMIClient 127.0.0.1
Of course, you'd replace c:\test3\wideopen.policy with the full path to your own properties file.
Here is another policy file that includes only the permissions necessary to run this app.




And that's the whole story of how to create and run an RMI program. It's really not that bad, is it? :-)
Here's the source code:
myRMIInterface.java
myRMIImpl.java
myRMIServer.java
myRMIClient.java

Describing the .NET Framework 3.0

Describing the .NET Framework 3.0

The goal in
application development is always the same: create the best possible
software in the least amount of time. Yet the bar is continually
raised, as the platforms on which developers build get better and
better. In Windows, for example, the original Win32 interface has been
subsumed by the much more functional .NET Framework. Both version 1.0
of the Framework, released in 2002, and version 2.0, released in 2005,
provide a significantly better and more productive environment for
people who design and write Windows software.

The .NET Framework
3.0 (formerly known as WinFX) is the next step in this progression.
Applications built on this new version of the Framework can be created
with Visual Studio 2005, making it feel familiar to most Windows
developers. But the .NET Framework 3.0 is also an evolution, adding
more to what version 2.0 of the Framework already provides. Scheduled
to be released in late 2006, the .NET Framework 3.0 will be available
for Windows Vista, Windows Server 2003, and Windows XP.

This
paper provides a big-picture view of the .NET Framework 3.0 and its
components. The goal is to make clear what this new release is, examine
how its technologies can be used, and provide brief explanations of
those technologies.

Building Modern Applications: The Challenges

Creating
a typical application today is not a simple task—the requirements are
substantial. Traditional concerns such as working with stored data and
allowing access through a Web browser are still important, but they're
no longer enough. Modern applications also present a range of new
challenges, including the following:

• Organizations are increasingly taking a
  process-oriented view of what they do. Since most applications automate
  some part of a business process, it can be useful to make the steps in
  this process explicit in the code. An effective way to do this is by
  using workflow technology, an approach that requires support for workflow-based applications.
• Applications
  commonly communicate with other applications, both inside and outside
  the organization. Modern applications also must often fit into a
  service-oriented architecture (SOA), exposing some of their
  functionality as interoperable services accessible by other software.
  Achieving these goals requires support for service-oriented applications.
• The
  people who use an application commonly need a way to convey information
  about who they are. Many different technologies for defining and using
  a digital identity are in use, and problems such as phishing are
  common. Given this, a modern application and the people who use it can
  benefit from consistent user control of digital identities.
• The
  requirements for a modern user interface have grown significantly.
  Providing real business value can commonly require working with various
  kinds of documents, using two- and three-dimensional graphics,
  displaying video, and more. All of this also needs to be available for
  both native Windows clients and Web browsers. Meeting these needs
  requires a unified approach to diverse user interfaces.

Given
that today's applications commonly need to tackle some or all of these
challenges, the platform those applications are built on should also
address all of them in a coherent and usable way. The goal of the .NET
Framework 3.0 is to do exactly this for Windows applications.

Addressing the Challenges: What the .NET Framework 3.0 Provides

As
figure 1 shows, version 3.0 of the .NET Framework builds on the
previous release. In fact, nothing in version 2.0 of the .NET Framework
is changed, so existing applications created for this foundation will
continue to work as always. The .NET Framework 3.0 does add four new
components, however: Windows Workflow Foundation, Windows Communication
Foundation, Windows CardSpace, and Windows Presentation Foundation.
This section takes a brief look at what the .NET Framework 2.0 and each
of these new components provides.

Figure 1

The .NET Framework 2.0: A General-Purpose Foundation for Windows Applications

While
it's still possible to write software that directly uses the Win32
interface, the .NET Framework has become the mainstream environment for
new Windows applications. Among its most important parts are the
following:

• ASP.NET, which supports the creation of Web-accessible applications.
• ADO.NET, allowing applications to access relational and other types of data.
• Windows Forms, supporting the creation of graphical user interfaces (GUIs) for Windows applications.
• System.XML, which lets applications work with XML-defined data, including using XSLT and XPath.

Version
2.0 of the Framework added several useful things to its predecessor,
including substantially improved technology for creating ASP.NET Web
applications, support for 64-bit applications running on 64-bit
versions of Windows, and a new approach to handling transactions. While
some parts of the .NET Framework 2.0 are largely superseded by the new
components added in version 3.0, as described later, the technologies
in version 2.0 remain a fundamental part of this new release.

Windows Workflow Foundation: Support for Workflow-Based Applications

A
workflow is a simple idea: it's just a series of steps performed in
some order. One might even argue that every application implements a
workflow, since every application executes some process. Yet the
traditional approach to creating an application using C# or Visual
Basic or some other programming language is to make the steps in this
process implicit in the code. This certainly works, but it also embeds
the process itself deeply into a program's logic, making that process
more difficult to implement and to change.

Using workflow
technology to implement process logic can be an effective way to
address this problem. Rather than intertwining the logic in ordinary
code, each step in the process is explicitly defined, then executed by
a workflow engine. The result is a clean implementation of the process itself.

Workflow
engines are not a new idea; several are available today for Windows and
for other systems. Microsoft even provides workflow engines embedded in
some of its products. Yet because workflow is becoming a mainstream
approach to creating applications, providing a single workflow
technology for Windows makes sense. This is exactly what's done by
Windows Workflow Foundation (the official acronym for which is WF).
By providing a common workflow technology for Windows, WF gives any
workflow-based application the same foundation to build on. Software
provided by Microsoft will use WF, including the Microsoft Office 2007
system and Windows SharePoint Services, as will applications created by
others.

Providing a common workflow technology presents some
challenges, however. For instance, how can a single approach meet the
diverse set of requirements presented by different workflow
applications? The answer adopted by WF is to take a very general view
of workflow. As figure 2 shows, a WF workflow is just a group of activities
that are executed by the WF engine. Each activity is actually a class,
and it can contain any work that the workflow's creator deems
necessary. Activities can potentially be reused across different
workflows, making it easier to create automated solutions to new
problems.

Figure 2

Another
challenge in providing a common workflow technology stems from the
traditional division between human-oriented and system-oriented
workflows. Workflow applications that are used primarily by people need
to be flexible, allowing things such as on-the-fly changes to the
process. Those used primarily by systems, that is, by software, tend to
be more static, but must be as efficient as possible. WF is intended
for both kinds of uses, and so it includes human-oriented features,
such as the ability to make changes to a running workflow, along with
support for more system-oriented behaviors.

By providing a
common workflow technology for Windows in WF, the .NET Framework 3.0
makes this useful paradigm for building software generally available to
developers. As a process-oriented view of software continues to gain in
popularity, the use of workflow will likely grow as well.

Windows Communication Foundation: Support for Service-Oriented Applications

Whether
they're built using workflow or with some other approach, most
applications need to communicate with other applications. How this
communication is done has taken a big step forward in the last few
years. After decades of disagreement, all of the major vendors have
agreed to support the same protocols for application communication.
Based on SOAP, this global agreement on Web services makes
interoperability between applications built on different technology
platforms, such as J2EE and the .NET Framework, significantly simpler
than it has been in the past. It also makes the idea of
service-oriented architecture much more plausible for most
organizations.

Plenty of approaches to communication already
exist, of course. In the .NET Framework 2.0, for example, the choices
include the following:

• ASP.NET Web Services, providing interoperable SOAP-based communication.
• .NET Remoting, focusing on communication between .NET applications.
• Enterprise Services, offering support for scalable, transactional applications.
• System.Messaging, supporting queued messaging through Microsoft Message Queuing (MSMQ).
• Web
  Services Enhancements (WSE), an extension to ASP.NET Web Services that
  provides support for more recent specifications such as WS-Security.

All
of these technologies have value, and all have had a role to play. Yet
why are there several different solutions to address what is
essentially the same problem? Why not instead create a single
foundation for application communication based on interoperable
services?

This is exactly what's done by Windows Communication
Foundation (WCF). Rather than requiring developers to use a different
technology with a different application programming interface for each
kind of communication, WCF (originally code-named "Indigo") provides a
common approach using a common API. In the .NET Framework 3.0
environment, most applications that might have used one of the
technologies just listed will instead use WCF for communication.

WCF
provides strong support for interoperable communication through SOAP,
an essential part of modern computing. This includes support for
several of the WS-* specifications, including WS-Security,
WS-ReliableMessaging, and WS-AtomicTransaction. WCF doesn't require
SOAP, however, and so other approaches can also be used, including an
optimized binary protocol, queued messaging using MSMQ, and simple
REST-based communication. WCF also takes an explicitly service-oriented
approach to communication. Rather than attempt to provide transparent
communication between objects, WCF interposes the slightly different
abstraction of a service between the communicating parties. One result
of this is to loosen some of the tight couplings that can exist in
distributed object systems, making interaction less error-prone and
easier to change.

Communication between applications, whether
within an organization or across organizations, is a fundamental part
of modern software. The .NET Framework 3.0 addresses this challenge by
using the service-oriented approach of WCF.

Windows CardSpace: Consistent User Control of Digital Identities

Think
about how people represent themselves today on the Internet. In the
majority of cases, a person's digital identity is expressed as a simple
username. Combined with a password, this identity is used to access
email accounts, Internet merchants, and even on-line banks and other
financial institutions. Yet despite their simplicity (and ubiquity),
usernames and passwords have several drawbacks. Here are the two most
important:

• People have a hard time remembering all of
  the usernames and passwords they've chosen for different sites. Many
  people use the same values for different sites, easing the memory
  problem but increasing the security risk.
• Usernames,
  passwords, and other personal information can be stolen by phishers. By
  sending deceptive emails, phishers entice their victim to log in to a
  Web site that looks just like, say, the site of the victim's bank. The
  site is actually controlled by the phisher, however, and so once the
  victim enters his username and password, the phisher can use this
  information to masquerade as the user at the real site.

Reducing
the severity of these problems requires a new approach to managing
digital identities. Windows CardSpace, originally code-named
"InfoCard," is an important part of that approach. To help people keep
track of their digital identities, CardSpace represents each identity
as a distinct information card. If a Web site accepts CardSpace
logins, users attempting to log in to that site will see a CardSpace
selection screen like the one shown in figure 3. By choosing a card,
users also choose a digital identity that will be used to access this
site. Rather than remembering a plethora of usernames and passwords,
users need only recognize the card they wish to use. Different cards
can also contain different information, allowing users to control
exactly what each site learns about them.

Figure 3

The identities represented by these cards are created by one or more identity providers.
Any organization can offer an identity provider, and rather than
relying on simple usernames and passwords, the identities each one
provides will typically use stronger cryptographic mechanisms to allow
users to prove their identity. CardSpace itself also includes a
self-issued identity provider that runs on client machines. With this
provider, users can create their own identities that don't rely on
passwords for authentication. Web sites can accept these self-issued
CardSpace identities rather than relying on the usual password-based
approach, reducing the problems that passwords bring.

If
passwords aren't used to log in to a site, phishers can't steal those
passwords. Still, if phishers can trick a user into logging into a
bogus site, they might be able to acquire other information from the
user, such as sensitive medical information. Preventing this requires
that users be able to distinguish real sites from the look-alike fakes
created by phishers. To allow this, the organization that owns a Web
site can get a high-assurance certificate. Unlike today's
simple SSL certificates, acquiring this new kind of certificate
involves a much more rigorous process, including stronger proof that
the organization applying for it actually is who it claims to be. A
high-assurance certificate can also carry a company's logo and other
information to help the user correctly determine whether a site using
this certificate is legitimate. When a user accesses a new site,
CardSpace always displays the information in that site's certificate
using a standard screen. Based on the strength of the certificate
received, this screen will indicate different levels of assurance of
the site's identity. The goal is to force users to make an explicit
decision to trust a site, then help them make the right choices about
which sites to trust.

Windows CardSpace is actually part of a larger identity metasystem.
Based entirely on open, public protocols, this metasystem defines a way
to use different digital identity technologies consistently across
diverse platforms (including operating systems other than Windows) and
diverse applications (including Web browsers other than Internet
Explorer). By providing a common way to select identities and more for
Windows, CardSpace fills a key role in the metasystem. And by
addressing the fundamental problem of identity, CardSpace also plays an
important part in the .NET Framework 3.0.

Windows Presentation Foundation: A Unified Approach to Diverse User Interfaces

The
user interface is an important part of nearly every application. Yet
what users expect from those interfaces has advanced significantly.
Traditional menu-driven GUIs are still required, of course, but
applications may also need to display video, run animations, use two-
and three-dimensional graphics, and work with various kinds of
documents. And all of this must be possible whether the application is
accessed from a stand-alone desktop client or through a Web browser.

Traditionally,
all of these aspects of the user interface have been provided in
different ways on Windows. For example, a developer can use Windows
Forms, part of the .NET Framework, to build a Windows GUI. Creating a
Web browser interface requires using HTML and perhaps Java applets or
JavaScript code. Displaying video might rely on Windows Media Player or
software such as Adobe's Flash Player, while document formats might be
defined by Microsoft Word or Adobe's PDF or something else. The
challenge for developers is clear: building a coherent user interface
for different kinds of clients using diverse technologies isn't simple.

A
primary goal of Windows Presentation Foundation (WPF), originally
code-named "Avalon," is to address this challenge. By offering a
consistent technical underpinning for all of these user interface
aspects, WPF makes life simpler for developers. By taking a more modern
approach, including support for video, animation, two- and
three-dimensional graphics, and various kinds of documents, WPF can let
users work with information in new ways. And by providing a common
foundation for desktop clients and browser clients, WPF makes it easier
to build applications that address both.

The example interface
shown in figure 4, containing images, live graphics, three-dimensional
views, and more, illustrates some of what WPF provides. Rather than
requiring developers with skills in diverse technologies, user
interfaces like this one can now be created in a more consistent way.

Figure 4

One
challenge that has long faced the creators of user interfaces stems
from the different roles required for building effective interfaces.
Software developers are needed to create the logic behind the
interface, but they're rarely the best people to define the interface's
look and feel. Designers, specialists in human/machine interaction, are
typically a much better choice for this role. Yet older technologies
such as Windows Forms are focused entirely on the developer. There's no
truly effective way for developers and designers to collaborate. To
address this problem, WPF relies on the eXtensible Application Markup
Language (XAML). An XML-based language, XAML allows specifying a user
interface declaratively rather than in code. This makes it much easier
for tools to generate and work with an interface specification based on
the visual representation created by a designer. In fact, Microsoft is
providing a new product, Expression Interactive Designer, to do exactly
this. Designers will be able to use this tool (and others provided by
third parties) to create the look of an interface, then have a XAML
definition of that interface generated for them. The developer imports
this definition into Visual Studio, then creates the logic the
interface requires.

When developers create a stand-alone WPF
application, one that runs directly on Windows, they have access to
everything WPF provides. To create a client that runs inside a Web
browser, however, developers can build an XAML browser application, commonly referred to as an XBAP. Built
on the same foundation as a stand-alone WPF application, an XBAP allows
presenting the same style of user interface within a downloadable
browser application. The same code can potentially be used for both
kinds of applications, which means that developers no longer need
different skill sets for desktop and browser clients. As is typical for
this kind of rich Internet application, an XBAP downloaded from the
Internet runs in a secure sandbox, which limits what the application
can do. Still, a large subset of the user interface functionality
available to a stand-alone WPF application can also be used in an XBAP.

Both WPF stand-alone applications and XBAPs can take advantage
of WPF's modern graphics support, including the ability to use hardware
acceleration, support for vector graphics, and more. By providing
support for more powerful graphics, WPF makes possible a range of data
visualization options that aren't possible with Windows Forms or other
earlier technologies. WPF also provides the foundation for the XML
Paper Specification (XPS), which defines a standard format for viewing,
distributing, and printing fixed-format documents.

User
interfaces are a complex and important part of modern applications.
Through WPF, the .NET Framework 3.0 presents a more complete and
consistent solution to the challenges these interfaces present. The
goal is to let people who create user interfaces—both developers and
designers—do their jobs more effectively.

Applying the .NET Framework 3.0: A Scenario

One
way to understand how a group of technologies works together is to look
at an example of how they can be used. Imagine, for example, an
application that lets customers and agents submit insurance
applications. If it were implemented using the .NET Framework 3.0, this
application might look something like figure 5.

Figure 5

The
application's business logic, shown in the upper left of the diagram,
is implemented using a WF workflow. Handling an application for
insurance is a multi-step process, including evaluating the application
against this organization's underwriting rules, perhaps checking the
applicant's credit, and maybe even getting a manager's approval. The
workflow implements each of these steps as an activity, relying on
other software as needed. To access stored data, for instance, the
activities in this workflow use ADO.NET.

This insurance company
provides a call center, allowing its customers to apply for insurance
over the phone. The client software used by the people staffing that
call center, shown in the upper right of the diagram, is implemented as
a stand-alone WPF application. This client communicates with the
application's business logic using WCF, using a binary protocol
optimized for WCF-WCF communication. As the figure shows, the call
center workers rely on Windows CardSpace to select the identity they
will use when logging into this application.

Customers can also
apply for insurance over the Web, and insurance agents can submit
applications, as well. To allow this, the application uses ASP.NET to
communicate with Web browsers. As shown in the lower left corner of the
diagram, customers using Internet Explorer to access this application
through an ordinary HTML interface can still use CardSpace to select
the identity they wish to present. Third parties can also implement an
identity selection mechanism for other client operating systems and
browsers, allowing the identity metasystem to extend to non-Windows
clients and Web browsers.

Insurance agents who access this
application over the Internet may well need a more functional
interface. Accordingly, they can rely on an XBAP rather than a simple
HTML interface. As shown in the lower center of the diagram, this gives
those customers a large share of the user interface functionality
provided by the WPF desktop application used in the call center. Both
are built on the same foundation, and so the application's developers
can reuse the same code in the two types of clients. And as with the
other kinds of clients, agents can use CardSpace to select the identity
they wish to present to the application.

Finally, it's likely
that this application will need to access and be accessed by other
applications. If approving a customer requires a credit check, for
example, this will most likely be done through a call to an external
service. Or perhaps the application accepts requests directly from
other software, exposing services that these external applications can
invoke. For cases like these, shown in the lower right of the figure,
the application relies on WCF to communicate using standard Web
services. Whatever technology these applications are built on, WCF's
support for SOAP makes interacting with them straightforward.

This
scenario illustrates how some of the .NET Framework 3.0's most
important components might be used in a typical application. Quite a
few options have been omitted, and so don't view this simple example as
a complete illustration of what this technology family provides.
Instead, the goal is to give a clear idea of how the various parts of
the .NET Framework 3.0 can be used in concert to address real business
problems.

Understanding the .NET Framework 3.0: The Technologies

To
really get a feel for what the .NET Framework 3.0 provides, it's useful
to dig a little deeper into each of its constituent technologies. This
section provides a short tutorial on each of the five parts of the .NET
Framework 3.0. For a more detailed introduction to each one, see For
Further Reading at the end of this paper.

The .NET Framework 2.0

Figure 6

The
.NET Framework 2.0 is a fundamental part of Windows development today,
and it's also the foundation of the .NET Framework 3.0. Figure 6
illustrates the Framework's two parts: the Common Language Runtime
(CLR) and the .NET Framework class library. Some components of the .NET
Framework 3.0, including WF, WCF, and WPF, are implemented largely as
extensions to the .NET Framework class library. As described earlier,
however, while many parts of the class library remain an important part
of a developer's world, others are subsumed by new technologies
provided by the .NET Framework 3.0. ASP.NET, for example, is still the
foundation for creating browser-accessible applications, and ADO.NET is
still used to work with stored data. .NET Framework 3.0 developers
might use WPF rather than Windows Forms to create a native Windows GUI,
however, and they'll typically prefer WCF over ASP.NET Web Services,
.NET Remoting, or Enterprise Services. Despite these changes, it's
important to understand that even in a NET Framework 3.0 world, the
previous version of the Framework remains a central part of a
developer's life.

Windows Workflow Foundation

A
process-oriented design, driven by a workflow, can be the right
approach for a significant fraction of Windows software. The purpose of
WF is to let developers create and execute these workflow-based
applications. Figure 7 shows the components WF provides to do this.

Figure 7

As
described earlier, every workflow is built from some number of
activities. Both workflows and activities are just classes, so both can
be created directly in code. WF also provides the Workflow Designer, a
Visual Studio-hosted graphical tool for constructing workflows. However
a workflow is created, its activities can be drawn from the Base
Activity Library (BAL) provided with WF or from any other source.

Once
a workflow has been defined, it's eventually executed by the WF runtime
engine. This engine relies on a group of runtime services for
persisting the workflow's state, tracking the workflow's execution, and
more. All of these things—the runtime services, the runtime engine, and
the workflow itself—are contained within some host process. This
process can be any Windows process, ranging from a simple console or
WPF application running on a desktop to a scalable server process.

Understanding
WF requires knowing at least a little about all of its components. The
following sections take a brief look at each one.

Workflows

Stripped
to its essentials, a workflow is nothing more than a group of
activities. WF provides built-in support for two styles of workflow:

• Sequential workflows, which execute
  activities in a defined order. Like a traditional flow chart, a
  sequential workflow can contain branches, loops, and other control
  structures. By default, however, activities execute in sequence, one
  after another.
• State machine workflows, which implement a
  traditional finite state machine. Like any state machine, which
  activity executes at a particular time is determined by the combination
  of the current state and whatever event has been received.

The
sequential option is useful for well-defined workflows, such as those
used in purely software-based processes. They're relatively simple to
create and understand, and they initially feel more natural to most
developers. State machine workflows are a better choice when the path
of execution is less predictable. A good example of this is a workflow
that involves interactions with people, any of whom can cancel the
workflow at any point. Addressing this situation with a sequential
workflow is possible, but every step could be a branch: Do this if the
workflow isn't cancelled, do something else if it is cancelled.
Modeling this kind of behavior using a state machine is significantly
simpler, since a request to cancel the workflow is just another event
that can be received and handled at any point.

Support for state
machine workflows is one example of how WF attempts to provide support
for human as well as system workflow. Another example of this is WF's
support for changing a running workflow. People can be capricious, and
it's not uncommon for someone involved in a workflow to wish to add a
step, delete a step, or make some other change in the process while
it's underway. To accommodate this in a controlled way, WF allows the
developer who creates a workflow to specify whether and how that
workflow can be modified while it's executing.

The Base Activity Library

Developers
are free to create custom activities. In fact, Microsoft's goal is to
foster the growth of a WF ecosystem full of reusable activities. Still,
starting with a common set of fundamental activities makes life simpler
for everyone. Providing this common set is the role of the Base
Activity Library (BAL).

A workflow isn't required to use
anything from the BAL. Still, many developers will find that the BAL
makes their lives simpler, especially at first. Among the activities
contained in the BAL are the following:

• IfElse: executes the activities contained in two or more possible paths based on whether a condition is met.
• While: repeatedly executes one or more activities as long as a condition is true.
• Sequence: executes a group of activities one at a time in a defined order.
• Parallel: executes two or more groups of activities in parallel.
• Code: executes a defined chunk of code.
• Listen: waits for a specific event, then executes one or more activities when that event is received.
• InvokeWebService: calls a Web service.
• State: represents a state in a workflow's state machine.
• EventDriven:
  defines a transition containing one or more activities that should be
  executed when a specific event is received while in a particular state.
• Policy: allows defining and executing business rules using a WF-supplied rules engine.

Rather
than define a particular language for specifying workflows, WF instead
takes the more general approach of using activities. The BAL provides
one "language," but everybody using WF is free to define their own, as
well.

Tools for Windows Workflow Foundation: The Workflow Designer

One
of the advantages of creating applications using workflows is the
ability to define the workflow graphically. WF's Workflow Designer
allows this, as shown in figure 8. By default, the activities in the
BAL appear in the Toolbox, letting a developer drag and drop them onto
the tool's design surface to create a workflow.

Figure 8

Some
developers prefer to write code—they don't like graphical designers. WF
allows this approach, too (and sometimes requires it: activities are
generally built directly in code). It's also possible to combine the
two approaches, creating a workflow using both the Workflow Designer
and direct coding. The goal is to let developers use the approach
that's most productive for them. And to allow broader tool support,
workflows can also be expressed in XAML, the same language used by WPF.
In fact, workflows created using the Workflow Designer default to a
XAML definition.

The Runtime Engine and Runtime Services

As
described earlier, the WF runtime engine has the job of executing the
activities in a workflow. As part of doing this, it relies on a group
of runtime services. WF includes standard implementations of these
services, but ambitious developers can replace them if desired. These
services support a few different things, but two stand out as most
interesting:

• Persistence: A workflow that's blocked
  waiting for some event can use this service to have its in-memory state
  automatically persisted to disk. When the event occurs, the service
  will automatically reload the workflow's state and restart execution.
  This is especially useful for workflows that involve people, since
  hours, days, or more might elapse while waiting for a response.
• Tracking:
  The activities in a workflow cleanly demarcate the execution of the
  process they implement. WF's tracking service allows a developer to
  cause information about the workflow's execution to be automatically
  written to a database. For example, a developer might wish to track
  when a workflow starts and ends, when each of its activities starts and
  ends, and other information.

Windows Workflow Foundation and Other Microsoft Technologies

Introducing
new approaches inevitably influences what already exists. The new
technologies in the .NET Framework 3.0 are no exception, and each one
has an impact on other Microsoft technologies. With WF, the initial
impact is felt most strongly by Windows SharePoint Services, the
Microsoft Office 2007 system, and BizTalk Server.

To let
developers more easily create workflow applications for document
collaboration and other kinds of information sharing, Windows
SharePoint Services, version 3 hosts the WF runtime. Office SharePoint
Server 2007, part of the Office 2007 system, builds on the WF support
in Windows SharePoint Services. Among other things, adding this server
allows displaying InfoPath forms directly in Office 2007 client
applications and using a set of pre-defined workflows for common
scenarios such as approving a document.

Anyone familiar with
BizTalk Server has certainly noticed by now the similarity between this
product's orchestration capabilities and what WF provides. In fact, the
release following BizTalk Server 2006 will replace the product's
existing orchestration function with WF, providing tools to help
migrate existing orchestrations to WF workflows. It's important to
understand, however, that WF and BizTalk Server 2006 address quite
distinct problems:

• WF provides a general framework for creating
  workflow-based Windows applications. It can be hosted in any process,
  use any kind of activities, and address any kind of business problem,
  including both human and system workflows.
• BizTalk Server is a
  licensed product focused on enterprise application integration,
  business-to-business integration, and managing business processes. It
  offers a large set of adapters for connecting to diverse systems and
  software, accelerators for implementing standards such as RosettaNet
  and SWIFT, and support for business activity monitoring. BizTalk Server
  also provides a management infrastructure and tools, along with support
  for increased scalability.

Because it's the standard
workflow technology for Windows, WF may well show up in other Microsoft
products and technologies in the future. Whatever Microsoft chooses to
do, WF will certainly find a home in a number of applications created
by its customers.

Windows Communication Foundation

The
change to service-oriented communication marks a shift in how
applications interact. Explicitly designed to support service-oriented
applications, WCF reflects this shift. This section describes the most
important aspects of WCF, including services and clients, communication
options, and support for security, reliable communication, and
transactions.

Services and Clients

Figure 9

As
figure 9 shows, the fundamental idea of WCF is simple: a service
exposes an interface that can be accessed by a client. That interface
can be defined using the Web Services Description Language (WSDL), then
turned into code, or it can be defined directly in a language such as
C# or Visual Basic. For a simple interface exposing an insurance
application service, the latter approach might look something like this:

[ServiceContract]
interface IInsuranceApplication
{
[OperationContract]
int Submit(int policyType, string ApplicantName);

[OperationContract]
bool CheckStatus(int applicationNumber);

[OperationContract]
bool Cancel(int applicationNumber);
}

The definition of this C# interface is marked with the ServiceContract
attribute. This attribute indicates that WCF can expose methods in this
interface as remotely-callable operations. Which of the interface's
methods are exposed depends on which are marked with the OperationContract
attribute. In this simple example, every method is marked with this
attribute, and so all of them will be exposed to remote callers. This
isn't required, however—it's legal to apply OperationContract
to only some of an interface's methods. Whichever choice is made, some
class in the application must implement this interface, providing
actual code for the methods the interface defines. Once this is done,
WCF automatically makes the methods marked with OperationContract accessible to clients of this service.

Figure
10 gives a slightly more detailed view of how a service is actually
exposed to its clients. Rather than access an interface directly, a
client instead connects to a specific endpoint. A service can expose multiple endpoints, potentially allowing different clients to access it in different ways.

Figure 10

As the figure shows, each endpoint specifies three things:

• A contract describing the operations
  that can be invoked using this endpoint. The contract can be identified
  using just the name of the interface that defines these operations,
  which here is IInsuranceApplication.
• A binding defining
  how the endpoint's operations can be invoked. Each binding defines
  several things, including what protocol should be used to invoke the
  operations, what kind of security should be used, and more. WCF
  includes a set of pre-defined bindings, such as the BasicHttpBinding
  shown here, for the most common cases, and it's also possible to define
  custom bindings. Because a single service can expose multiple
  endpoints, it can simultaneously allow access to different kinds of
  clients over different protocols and with different security options.
• An address indicating where this endpoint can be found. As shown in the figure, the address is represented as a URL.

The
basics of WCF are simple. As with most communication technologies, the
details can get complex—there are many options—but creating ordinary
WCF applications isn't hard.

Communication Options

Different
kinds of applications built by different kinds of developers need
different ways to communicate. The simplest approach for most
developers is remote procedure call (RPC), which lets a client invoke
remote operations much like local ones. Given the interface shown
earlier, for example, a client could invoke any operation in the usual
synchronous way, waiting patiently until a response comes back. This
option is easy for developers, and it's the right choice in some
circumstances.

WCF also provides several other options, however. They include the following:

• Calls that have no response. Marked with the attribute OneWay, this kind of communication can be useful for sending events or other one-way interactions.
• Asynchronous message-based communication, using direct sends and receives with XML messages.
• Explicit manipulation of SOAP messages, including the ability to insert elements directly in the SOAP header.

WCF also allows developers to control various local aspects of how a service behaves. Using the ServiceBehavior
attribute, for example, they can set whether the service is single or
multi-threaded, whether a new instance of the service is created for
each call, and other options.

Security, Reliability, and Transactions

Basic
communication—the ability to move data between systems—is useful, but
it's rarely enough. Most applications need more. For example, the great
majority of distributed applications need some kind of security.
Providing security can be complex, given the range of different
approaches and diversity of technologies in use today. To let
developers create secure distributed applications without forcing them
to understand all of the details, WCF relies primarily on bindings for
security. For example, the BasicHttpBinding shown earlier can be
configured to use HTTPS rather than plain HTTP, and other bindings
provide more security options. WsHttpBinding, for instance, supports
WS-Security, allowing interoperable SOAP-based authentication, data
integrity, and data confidentiality. Developers can also create a
custom binding that provides the exact security services their
application needs.

Making sure that communication is reliable is
also essential for many applications. The traditional Web services
approach, sending SOAP over HTTP, is sufficient in some cases, and it's
what's done when the BasicHttpBinding is used. There are plenty of
situations, however, in which this widely-used choice isn't enough.
Messages that go through one or more SOAP intermediaries, for instance,
can't rely on this simple approach for end-to-end reliability. For
these cases, WCF implements WS-ReliableMessaging. By choosing a binding
that supports this option, such as WsHttpBinding, a developer can
automatically get interoperable reliable message transfer.

Distributed transactions can also be important in some applications. WCF builds on System.Transactions, part of the .NET Framework 2.0, to allow the creation of transactional software. A method can use the OperationBehavior
attribute to indicate that it requires a transaction and to define how
that transaction behaves. To allow distributed transactions that are
interoperable across vendor boundaries, WCF relies on the
WS-AtomicTransaction specification. Using the technology defined in
this multi-vendor agreement, WCF applications can participate in
transactions that span diverse technologies, including J2EE and others.

Windows Communication Foundation and Other Microsoft Technologies

As
mentioned earlier, WCF supersedes several earlier Microsoft
technologies for creating distributed applications. Most applications
that would have been built using ASP.NET Web Services, .NET Remoting,
Enterprise Services, System.Messaging, or WSE will instead be built on
WCF. WCF applications can interoperate with ASP.NET Web Services
applications—both support standard SOAP—as well as applications built
on Enterprise Services, MSMQ, and version 3.0 of WSE. WCF can also be
used by BizTalk Server 2006, and a future version of BizTalk Server
will build even more directly on what WCF provides.

It's
important to understand that even though new .NET Framework 3.0
applications won't commonly use them, all of the technologies that WCF
supersedes are still part of this version of the Framework, and they'll
all be supported as usual. Applications built using earlier versions of
these technologies will also continue to run normally; installing and
using the .NET Framework 3.0 won't break existing code.

Windows CardSpace

Whether
it's through a Web browser or some other kind of client, users
routinely access applications across a network. Since these
applications commonly require users to identify themselves in some way,
the inescapable corollary is that people are regularly forced to
acquire and present identity information to remote software. Accessing
Internet applications through a browser provides a very common example
of this, and users on intranets commonly face the problem as well.

As
described earlier, people most often rely on usernames and passwords
for digital identities today, with all of the problems this entails.
Windows CardSpace, part of the larger identity metasystem, offers an
alternative approach to addressing these problems. To get a deeper
understanding of how CardSpace does this, the place to start is with
the basic concepts of the identity metasystem.

Windows CardSpace and the Identity Metasystem

When
users access an application, whether from a Web browser or an
application-specific client or something else, they commonly present
some kind of digital identity. Digital identities come in many
varieties, but virtually all of them are represented on the network by
a security token. While a simple security token can be just a
username, a more complex token might include an X.509 certificate or an
XML document. However they're represented, security tokens are today's
typical mechanism for representing digital identities on the network.

While
it's tempting to believe that we'll all one day adopt a common security
token format, the reality is that diverse approaches will continue to
be used. Just as we today carry multiple identity cards in our
wallet—drivers license, credit card, airline frequent flyer card, and
more—we'll always have diverse digital identities represented by
diverse kinds of security tokens. No single identity system can provide
a universal answer, and so multiple security tokens will always be
necessary.

Yet users still need some way to work consistently
with their diverse digital identities. Even though no single identity
system will suffice, it's possible to create a system of identity
systems—an identity metasystem—that allows using a myriad of digital
identities in a consistent way. Working with others, Microsoft has led
the process of defining this metasystem. Based on open Web services
technologies, such as WS-Security and WS-Trust, this metasystem defines
how digital identities can be acquired and used, regardless of the type
of security token they depend on.

The process of issuing,
acquiring, and using digital identities can be thought of as requiring
three distinct roles. Those roles are the following:

• User: Sometimes called the subject, the user is the entity that has a digital identity.
• Identity provider:
  An identity provider supplies a digital identity for a user. For the
  digital identity assigned to you by your employer, for example, the
  identity provider is typically a system such as Active Directory. For
  the digital identity you use with Amazon, the identity provider is
  effectively you, since you define your own username and password.
  Digital identities created by different identity providers can carry
  different information and provide different levels of assurance that
  users really are who they claim to be.
• Relying party:
  A relying party is an application that in some way relies on a digital
  identity. A relying party will frequently use an identity (that is, the
  information contained in this identity's security token) to
  authenticate a user, then make an authorization decision, such as
  allowing this user to access some information. A relying party might
  also use the identity to get a credit card number, to verify that the
  same user is accessing it at different times, or for other purposes.
  Typical examples of relying parties include Internet Web sites, such as
  banks, online merchants, and auction sites, and any application that
  accepts requests through Web services.

These three kinds
of entities interact in the identity metasystem. Figure 11 illustrates
these interactions, along with where CardSpace fits in.

Figure 11

The
process begins when a user accesses a relying party through a
CardSpace-aware application. To learn what type of security tokens this
relying party will request, the application must get the relying
party's policy (step 1). For a browser accessing a Web site, which is
likely to be the most common case, the site's policy is expressed in
HTML and sent back as part of a Web page. For applications accessed
through Web services, however, the application instead uses the
industry-standard protocol defined by WS-MetadataExchange to ask the
relying party for its policy. In this case, the policy is expressed
using WS-SecurityPolicy, another industry standard. However the policy
information is acquired, it always indicates what kind of security
tokens this relying party will accept and what information those tokens
must contain.

Once CardSpace knows what kind of security
tokens the relying party needs, it displays the identity screen shown
earlier. Each digital identity available to this user is represented as
an information card on this screen. Cards issued by an external relying
party are referred to as managed cards, while those issued by CardSpace's self-issued provider are known as self-issued
cards. Both kinds of cards can be shown on this screen, and the user
can potentially select one of either type. To make this decision
easier, the screen indicates which identities meet the requirements of
the relying party by graying out cards that don't qualify. The user
then selects one of these as the digital identity he wants to use (step
2).

A card doesn't contain an actual security token, however.
Instead, it holds the information necessary to locate a particular
identity provider and request a security token for this user. (In fact,
each card is originally created by some identity provider.) CardSpace
uses the contents of the card selected by the user to request a
security token from the identity provider that issued that card (step
3). This request is made using WS-Trust, another industry-standard
protocol, and users authenticate themselves to the identity provider
using Kerberos, an X.509 certificate and digital signature, or another
mechanism. The token is returned in an encrypted form, which also
contains a timestamp to prevent this token from being stolen off the
wire and reused in the future.

Once the requested security token
is returned, it's sent to the relying party (step 4). How the relying
party uses the information in the token can vary. If the token contains
an X.509 certificate, for example, and is accompanied by a digital
signature, the relying party will likely use the token to authenticate
the user. There's no requirement that tokens be used for authentication
or for any other security-related purpose, however. (In fact, the term
"security token" is a misnomer.) A token might carry information such
as proof of a user's age, eligibility for a discount at an Internet
shopping site, or anything else. Authentication is one important use
for security tokens, but it's not the only option.

It's
important to note that neither CardSpace nor the identity metasystem as
a whole is aware of the format or technology used for the security
token. Rather than trying to create a new single source for digital
identities or a standard format for security tokens, the goal of the
metasystem is to provide a coherent way to use any digital identity
based on any kind of security token. By providing a Windows
implementation of key parts of the metasystem, CardSpace plays an
important role in making this general approach to digital identity a
reality.

Fighting Phishing

Identity
providers are often distinct from the user, such as when an identity is
assigned by an employer. Yet there are plenty of situations in which
the identity provider is actually users themselves. If CardSpace isn't
used, for instance, accessing many Web sites requires giving a username
and password, both of which are defined by users. Once the users have
created this identity, they can later supply the username and password,
then check their bank balance, buy a book, or do whatever else this
site allows.

Because they depend on passwords, however, these
kind of self-issued identities are targets for attackers, as described
earlier. To help reduce these attacks, CardSpace provides an
alternative way to create a self-issued identity. This self-issued
identity provider runs locally on the user's Windows system. Rather
than relying on a username and password, the security tokens created by
the self-issued identity provider are defined using the Security
Assertion Markup Language (SAML), an OASIS-defined standard. These
tokens rely on public key technology rather than passwords to prove the
user's identity, and if a relying party accepts them, they can play the
same role as the traditional username and password. The advantage is
that there is no longer a password for phishers to steal. Reducing the
use of passwords, together with the stronger proof of a site's identity
provided by the high-assurance certificates described earlier, can make
phishing a much less serious problem.

Windows CardSpace and Other Microsoft Technologies

CardSpace is related to several other Microsoft technologies, including the following:

• WCF: Because it relies on Web services
  standards such as WS-Security and WS-Trust, CardSpace uses WCF for
  communication. In fact, the creator of a WCF application can cause that
  application to use CardSpace just by specifying a particular binding.
• Active Directory: Although it's not possible today, Active Directory will eventually be able to act as an identity provider in the metasystem.
• Windows Live ID (formerly known as Passport):
  As with Active Directory, Microsoft has announced that its Live ID
  authentication system will also be modified to act as an identity
  provider. Note that CardSpace isn't a replacement for Live ID, since
  the two address quite different problems. Instead, Live ID will become
  part of the identity metasystem just like any other identity provider.

Microsoft
also provides other identity-related technologies that address somewhat
different problems than CardSpace. Active Directory Federation Services
(ADFS), for instance, focuses on federating identities across
organizations. This is an important challenge, and it's faced by many
firms that need to work with other organizations. This problem is quite
distinct, however, from the broader issues addressed by CardSpace and
the identity metasystem.

Windows Presentation Foundation

Workflow-based
logic, service-oriented communication, and identity are all important
in modern applications. Yet users often care most about what they see:
the user interface. The goal of WPF is to address the challenges of
creating user interfaces for modern applications. As described next,
WPF provides a range of capabilities to do this.

The Capabilities of Windows Presentation Foundation

A
developer is free to create a WPF application's interface entirely in
C#, Visual Basic, or some other CLR-based language. As described
earlier, however, WPF also allows specifying an interface using the
XML-based XAML. Elements and attributes in XAML map directly to the
classes and properties that WPF provides. For example, here's a simple
button defined in XAML:

<Button Background="Red">
No
</Button>

This example creates a red button that contains the
text "No." The exact same result could also be produced with the
following code:

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";

However it's defined, virtually every WPF application
follows the same basic model. The application inherits from WPF's
standard Application object, which provides basic methods, events, and
properties. A WPF application can have either a traditional
dialog-driven interface or a navigational interface, letting it
function much like a browser application. An application built in the
latter style is typically implemented as a group of pages, each
consisting of a user interface defined in XAML together with some logic
defined in code. To link these pages together, XAML provides a
Hyperlink element, much like HTML. The application displays one page at
a time, lets a user move back and forth among its pages, maintains a
history list, and more. Although a navigation application can run
inside a Web browser as an XBAP, this isn't required; a developer is
free to use this interface style in stand-alone WPF applications, as
well. The goal is to create software that combines the best aspects of
a browser interface and a native Windows interface.

Whatever style its interface uses, a WPF application can rely on panels for basic layout. Each panel typically contains controls, and those provided by WPF include Button, TextBox, ComboBox, Menu,
and many more. How those controls are positioned depends on what type
of panel is chosen. A Grid, for instance, allows positioning controls
on a specified grid, while a Canvas lets the developer place controls
anywhere within its boundaries. And as usual in a GUI, events generated
by the user are caught and handled by the various controls and other
classes in the application. It's also possible to apply styles and
templates to groups of controls, which makes it easier for applications
to have a uniform look.

WPF supports much more than these basic user interface functions, including the following:

• Documents: A WPF application can display XPS documents using XAML's FixedDocument tag. An application can also display flow documents using the FlowDocument
  tag. A flow document can behave like a traditional on-screen document,
  allowing the user to scroll through its contents. By setting various
  attributes on this tag, however, a developer can make the document more
  adaptive to its surroundings. A document can display a page at a time,
  for example, freeing its reader from the need to scroll back and forth.
  WPF can also automatically determine how many columns a document should
  be broken into based on the size of the window in which it's displayed.
  The goal is to allow on-screen documents to be as readable as possible.
  
• Graphics: WPF includes support for creating
  two-dimensional and three-dimensional vector graphics. For 2D work, WPF
  provides standard abstractions such as shapes, brushes, and pens, while
  allowing 3D graphics to define a model that can be assigned lighting
  and camera position information. Unlike earlier technologies such as
  Windows Forms, which relies on GDI+ for graphics, WPF graphics aren't
  partitioned off using a separate set of concepts that developers must
  understand. Instead, the XAML elements used for graphics can be
  combined naturally with those used for anything else in a user
  interface. Buttons can have graphical content, text and graphics can be
  combined, and more.
• Images: Using XAML's Image
  tag, a WPF application can display images in various formats, including
  JPEG, GIF, and others. WPF relies on the Windows Imaging Component
  (WIC) to provide a standard framework for codecs, software that
  displays and stores images. As usual in WPF, an Image element can be combined with others, allowing things such as a button that displays an image rather than a simple text label.
• Media: A WPF application can use the MediaElement
  tag to display video and audio in various formats, including WMV, AVI,
  and MPEG. Once again, this element can be combined with other XAML
  elements, allowing things such as a 3D cube that displays video on its
  sides.
• Animation: WPF provides built-in support for
  animating most parts of a user interface. A circle can grow and shrink,
  for example, or a button can smoothly change size. Applications can
  also define storyboards containing timelines, allowing coordinated
  sequences of animations to occur.
• Data Binding:
  Because many WPF applications display data, it's useful to have
  automatic support for mapping data to user interface elements. WPF
  provides this kind of data binding for information contained in objects
  and other sources. WPF data binding also allows sorting and filtering
  data before it's displayed.

Applying Windows Presentation Foundation

WPF
provides a large set of user interface functionality, allowing
developers and designers to create very appealing user interfaces. Yet
no matter how lovely a client application looks, some organizations
might resist using it because of deployment issues. If rolling out a
new version of the client requires physically touching every desktop
machine that this application is installed on, the cost of upgrades can
be significant. One common way to avoid this problem today is to create
browser-based clients rather than native Windows clients. Yet native
Windows clients can generally have better, more responsive user
interfaces than browsers. To address the challenge of deploying these
clients, stand-alone WPF applications can be put into place using
ClickOnce. A technology that first appeared in the .NET Framework 2.0,
ClickOnce lets Internet Explorer users select an application over the
Web, then have it automatically installed on their local machine. Once
installed, the application can also be automatically updated when a new
version is made available. The goal is to combine the simplicity and
inexpensive deployment of a Web client with the power and functionality
of a stand-alone WPF application.

Especially when they're
deployed using ClickOnce, stand-alone WPF applications are a good
client choice in many situations. Yet there are cases where this kind
of application isn't appropriate, even when its users could benefit
from the kind of interface that WPF allows. Think about the remote
insurance agents in the scenario described earlier, for instance, or an
Internet merchant that wishes to provide 3D graphics, video, and the
other modern features that WPF supports. It often won't be reasonable
to expect this application's users to install a native WPF application
to access the site. A better solution would be to give users a
WPF-style interface inside their Web browser.

XAML browser
applications—XBAPs—are designed to do this. Rather than deploying a
stand-alone WPF application, an Internet Explorer user can download an
XBAP directly into the browser. Running inside Internet Explorer, this
application can then present the user with a WPF-based user interface.
Yet downloading and running code from Internet Web sites can be
dangerous. To protect the user from malicious developers, all XBAPs
downloaded from the Internet run in a partially trusted sandbox. Based
on the code access security provided by the .NET Framework, this
sandbox limits what XBAPs can do. For instance, an XBAP downloaded from
the Internet can't create stand-alone windows or launch new windows,
display a Save dialog launched by the XBAP itself, or access the file
system except in an isolated storage area. Yet despite the restrictions
imposed by the sandbox, an XBAP can still use a large fraction of WPF
functionality, including 2D and 3D graphics, animations, on-screen
documents, images, video, and more.

As described earlier, WPF lets applications display adaptive documents using XAML's FlowDocument
element. Documents whose appearance changes based on how they're
displayed aren't always the best solution, though. Fixed-format
documents, which always look the same on a screen and a printer, are
sometimes a better choice. WPF's XPS documents address this problem.
Defined using a subset of XAML, XPS documents can be read on any system
that provides an XPS reader. They also provide a new print format for
Windows, allowing complex graphics to be printed with more fidelity.
And to make working with different kinds of documents more consistent,
both XPS documents and Office 2007 documents use Microsoft's Open
Packaging Conventions, which define common ways to store document
content, digitally sign documents, and more.

Tools for Windows Presentation Foundation

It's
possible to create any WPF user interface directly in code and/or XAML
using a basic text editor. Most people would prefer to work with better
tools, however, and so Microsoft provides extensions to Visual Studio
2005 that let developers create WPF applications. The next release of
Visual Studio, code-named "Orcas," will provide still more capability
with the Visual Designer for Windows Presentation Foundation. Using
this tool, developers will be able to graphically create the user
interface they wish to see, then let the tool generate the code for
this interface.

Yet developers often aren't the best people to
define user interfaces. Designers are usually much better at this kind
of work, since they specialize in communicating with people. Most
designers don't write code, though, and so the Visual Designer for
Windows Presentation Foundation, hosted inside Visual Studio, isn't an
effective tool for this group. To let designers work effectively in the
WPF world, Microsoft has created Expression Interactive Designer. A
designer can use this tool to define the look and feel of an interface,
specify animations, and more, then let the tool generate an XAML
version of what is created. A developer can import this XAML into
Visual Studio and add code for things such as handling events. Because
both Visual Studio and Expression Interactive Designer use the same
build system, it's possible for developers and designers to work on a
project iteratively, each using the tool they're comfortable with. The
goal is to help people from the divergent disciplines of design and
software engineering work together effectively.

Windows Presentation Foundation and Other Microsoft Technologies

Like
other .NET Framework 3.0 components, WPF has an impact on existing
Microsoft technologies. The most important of these are the following:

• Windows Forms: The .NET Framework's
  original approach for creating application GUIs, Windows Forms is used
  in many applications today. Recognizing this, WPF allows Windows Forms
  controls to be hosted in WPF applications and WPF controls to be hosted
  in Windows Forms applications. For example, a Windows Forms application
  might host a WPF control that provides three-dimensional data
  visualization. While there are some limitations, creating applications
  that use both technologies is certainly possible. Note too that
  existing Windows Forms applications will continue to work unchanged in
  a .NET Framework 3.0 world.
• Win32 and Microsoft Foundation Classes (MFC):
  As with Windows Forms, it's possible to host WPF controls in existing
  applications built using these existing technologies, and vice versa.
  Interoperability is somewhat more complex than with Windows Forms,
  however, because unlike Windows Forms, Win32-based and MFC-based
  applications aren't build on the CLR. Accordingly, interoperability
  with WPF also requires mapping between CLR-based code and native Win32
  code.
• Direct3D: Part of the DirectX family of APIs,
  Direct3D lets applications create and display 3D graphics. With the
  advent of the .NET Framework 3.0, mainstream Windows applications can
  use the 3D capabilities in WPF rather than the more specialized
  approach that Direct3D provides. Still, some applications that need
  higher performance, such as 3D games, will continue to use Direct3D. In
  fact, under the covers, WPF relies on Direct3D for all rendering.
• Windows Communication Foundation:
  As was shown in the scenario earlier, WPF applications can use WCF.
  XBAPs typically cannot use WCF, however, because WCF requires full
  trust. Every XBAP downloaded from the Internet runs in a partial trust
  sandbox, which prohibits it from accessing WCF. XBAPs can use ASP.NET
  Web Services, however, allowing them to make SOAP calls that
  interoperate with WCF and other Web services implementations.
• "WPF/E":
  One more aspect of WPF is also worth mentioning here, even though it's
  not part of the .NET Framework 3.0. Code-named "WPF/E," its goal is to
  support WPF-style interfaces on systems that don't support WPF itself.
  As the "E" in its name suggests, this technology is meant to be
  available everywhere, including Macintoshes, small devices, and other
  systems. Scheduled to ship sometime after WPF itself, WPF/E will
  provide a subset of full WPF functionality, including 2D graphics,
  animation, and video.

Getting the .NET Framework 3.0: Distribution Options

For
an application to use the .NET Framework 3.0, this version of the
Framework must be installed on the machines this application runs on.
For Windows Vista, this is straightforward: The .NET Framework 3.0 is
installed by default. This means that new machines with Windows Vista
installed or existing machines upgraded to Vista will automatically be
able to run .NET Framework 3.0 applications. The .NET Framework 3.0 can
also run on Windows XP and Windows Server 2003, however. To make the
new .NET Framework 3.0 components available to existing users of these
systems, Microsoft will make this software available as a free
download.

Conclusion

The
.NET Framework 3.0 is the evolution of the Windows programming model.
Built on and extending the .NET Framework 2.0, its goal is to support
the creation of modern applications. To do this, version 3.0 of the
Framework provides a diverse set of technologies, each addressing a
significant challenge in application development today. By building
this diversity on a common foundation, Microsoft is striving to make
the whole greater than the sum of the parts, letting developers create
applications that use the various parts of the .NET Framework 3.0 in a
coherent way.

Whatever aspects of this new release an
organization chooses to adopt, the technology is certain to have a
substantial impact on the world of Windows software. For anyone who
works in this world—developer, architect, or decision-maker—the time to
start understanding how to benefit from the .NET Framework 3.0 is now.

Apply a Theme to Entire Web site (2.0)

Apply a Theme to Entire Web site (2.0)
In order to do this, you only need to set the theme in one place - your web.config file:

Adding a 'Friendly' name to an Email Submission

Adding a 'Friendly' name to an Email Submission
Adding a 'Friendly' name to either the 'To' or 'From' properties, in an ASP.Net form submission is fairly painless.

The format is like this:

objMail.To="Friendly Name 

Naturally, this applies for the 'To' and the 'From' properties. In addition, you can use dynamic email addressses like this:

objMail.To="Friendly Name <" & sEmail & ">"

And, finally, you can use a dynamic Email address along with a dynamic Friendly name like this:

objMail.To=sFriendlyName & "<" & sEmail & ">"

Add Item to Bound DropDownList

Add Item to Bound DropDownList
To add an item to the top of a DropDownList at any time, here's the code:
MyDDL.items.insert(0,"WhateverYouWantHERE")

The '0' shows that it needs to insert the item at the top position of the DropDownList item collection. The second part, "WhateverYouWantHERE" is the actual text you want displayed. You could also use this to put a blank item at the top:
MyDDL.items.insert(0,"")

or to specify both value and text:
Dim liItem as ListItem=New ListItem("text", "value")
MyDDL.Items.Insert(0, liItem)

Accessing Controls on Master Pages from Content Pages

Accessing Controls on Master Pages from Content Pages
Let's say you have a label called 'Label4' on your Master Page. You might want to change the text of that label, to something different, from each content page you have in your site. To do that, it's very easy:

Dim lbl As Label
     lbl = CType(Master.FindControl("Label4"), Label)
     lbl.Text = "whatever" 

(of course, this is all assuming the label is OUTSIDE the ContentPlaceHolder)

AccessDataSource - so easy

AccessDataSource - so easy
As you may or may not know, with ASP.Net v2.0, there are several DataSource controls, like SQLDataSource, and AccessDataSource. The AccessDataSource is even easier to use than the SQLDataSource.

There is no 'ConnectionString' property for the AccessDataSource, but there is a 'DataFile' property. All it requires is a path to the Access Database you want to use:

  Runat="Server"
  SelectCommand = "SELECT  EmployeeID,  LastName,  FirstName,  Title From  NWEmployees"
  DataFile="\data\northwind.mdb;">

[Your Field Name] is neither a DataColumn nor a DataRelation for table [Your Table Name].

[Your Field Name] is neither a DataColumn nor a DataRelation for table [Your Table Name].
If you're getting this message and you know beyond a shadow of a doubt that this field/column DOES, indeed, exist in your table, then, check your SQL query to make sure you included the field name in the query.
(Most likely, it was forgotten)

The two possible reasons are that, either it doesn't exist in the table, or it doesn't exist in the SQL query.

@@Identity in MS Access

MSAccess 2000 or later supports the @@IDENTITY property to retrieve the value of an autonumber field after an Insert is executed.

Check out the following MSDN Link:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconRetrievingIdentityOrAutonumberValues.asp

Submitted by : David Wier

code behind?

When referring to your code behind page, in your Page Declaration, if you are NOT using VS.Net, and using a text editor, use the 'Src' designation. The 'CodeBehind' designation is only relevant when using VS.Net...

Example:

<%@ Page Inherits="ClassName" src="main.vb" %>

who i am?

hello friend i will share my knowledge here with asp.net and c#. come here if you have query and let me know i will solve your query