The Component s Role in a Distributed System

The Component's Role in a Distributed System

In a distributed application, components contain classes that typically play one of two roles:

  • A provider of services

  • A container for information

Why the sharp distinction? In a distributed application, state is a critical issue (as discussed in Chapter 10). By using this distinction, you can separate classes that require state but don't provide much functionality (the information packages) from classes that provide a collection of utility functions and are entirely stateless (the service providers).

Note

Programming veterans might notice that I've studiously avoided bringing business objects into this discussion. In Chapter 10, we'll revisit the issue in more detail as we examine tiers and object modeling.


Service Providers

The most important role a class can play is that of a "provider of services" for your application. This type of class might provide services directly to the client front end, to another component, or to a third-party program that you have no interest in (as is often the case when you create a Web service). In this sense, a component has one goal: to facilitate the reuse and maintenance of a logically distinct piece of code. For example, you could design the perfect tracing or database class in a component, and then compile in a separate assembly. This is a pattern you'll see throughout this book.

Deciding to put functionality into a component doesn't mean much when you're dealing with distributed architecture. Any type of program can benefit from component-based programming. When you start thinking about partitioning your application into components, however, you open yourself to the possibility of hosting components out of process. Out-of-process components can still run on the same computer, or they can run on other computers. This is the essence of distributed application programming.

So how do you make a component that can be activated on another computer? It's a topic we'll return to in the next few chapters, but here's an overview of some possibilities:

  • Classes that inherit from System.MarshalByRefObject directly or indirectly can be activated across computers using .NET Remoting.

  • Classes that use the <WebMethod> attribute (and optionally inherit from System.Web.Services.WebService) can be accessed through ASP.NET as Web services.

  • Classes that inherit from System.EnterpriseServices.ServicedComponent are serviced components and gain everything that COM+ has to offer, including object pooling and just-in-time activation.

Information Packages

You might also want to create a class that should never be executed out of process but is intended to be part of a component assembly. The most common example is creating an "information package" basically, an object such as an Account class or a UserInfo class that contains a set of related properties that detail information about a single entity.

In this case, you might also want to add the <Serializable> attribute, which ensures that the component can be serialized and transmitted to other out-of-process components through .NET Remoting (no such step is necessary for XML Web services). We'll get into these considerations in more detail over the next few chapters.



Microsoft. NET Distributed Applications(c) Integrating XML Web Services and. NET Remoting
MicrosoftВ® .NET Distributed Applications: Integrating XML Web Services and .NET Remoting (Pro-Developer)
ISBN: 0735619336
EAN: 2147483647
Year: 2005
Pages: 174

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net