c-- styles for logos and headline links do not modify internet, red, or black styles -->

Intranet Journal   Earthweb  
Events Jobs Premium Services Media Kit Network Map E-mail Offers Vendor Solutions Webcasts

   Intranet Journal Subjects
Search Earthweb

Privacy Policy



internet.com
IT
Developer
Internet News
Small Business
Personal Technology

Search internet.com
Advertise
Corporate Info
Newsletters
Tech Jobs
E-mail Offers

internet commerce
Be a Commerce Partner
















 

[ Home | Discussion Forum | How Do I... | Lotus Notes Intranets | Microsoft SharePoint | Products | Shopping  ]

free news!

Developing ASP Components Active Server Pages
Click to purchase


By Shelley Powers

Chapter 1: Developing ASP Components

What Are ASP Components?

What Are ASP Components?

As stated earlier, ASP components are COM-based components that encapsulate a specific functionality and are invoked either directly from an ASP page or indirectly via some other ASP component. If you have worked with COM before, ASP components don't use any additional technology, but they can use additional objects available only within the context of an ASP application. However, if a component does not access the ASP-specific objects provided through the ASP object model, it can be used within a distributed application, from other components (whether or not they're part of an ASP application), or even within a flat one-tier application, with no involvement with ASP or IIS or even the Internet. From this point of view, this book could actually be about writing COM components, but with a specific focus.

Having said that an ASP component is really no different than any other COM component, I want to add that the focus of writing an ASP component can alter how that component is created. First of all, the component will usually reside on the same server as the "client" of the component, with the client for ASP being the web server. I say "usually" with some reservation, since there is no requirement that ASP components have to reside on the same server as the client application.

In addition, an ASP component is almost always an in-process (ActiveX DLL) component. As you will see in Chapter 3, ASP Components and COM, using an out-of-process component (an ActiveX executable) directly from an ASP page actually requires that the IIS installation be modified. ASP is optimized for in-process access of components.

As in-process COM objects, ASP components are usually created using apartment-, free-, or both-threaded models. ASP components are not and should not be created using the single-threaded model, since the component locks down all access to a single thread, which causes access problems in a multi-user environment such as the web and a multi-user application such as a web server. In addition, when using multithreaded models, the ASP components must be thread-safe. What's a thread-safe ASP component? One that does not contain global data, does not yield control internal to the processing of the component, and is safely reentrant. Chapter 4, ASP Components and Threads, goes into more depth on threads and apartments.

Now that you have a basic idea of what ASP components are, the next section discusses why you would use ASP components instead of creating the ASP application using scripting exclusively.

Why Use ASP Components?

In the beginning of the chapter, I started listing some reasons to use ASP components instead of scripting. In this section I want to discuss this in a little more detail.

From a perspective of usage, an ASP component can be used in place of scripting where scripting is just not workable or efficient. For example, your ASP application may need to make direct calls to the Windows internals through the Win32 API, or to manage file input and output. These operations cannot be done from within a scripting language such as JScript or VBScript. The IIS scripting engine can be extended to other scripting languages, such as Tcl or Perl, which do support direct file system access or calls to the Win32 API. However, the use of these scripting languages comes at a cost: the code is a little more difficult to read, a little more difficult to maintain, and a whole lot more difficult to secure against editing from external sources. If the code needs to remain unaltered, perhaps to enforce standards compliance or universal data access, the code should be contained within binary components.

Along with implementing functionality that is either unsupported or not easily supported by scripting languages, ASP components are also developed to be reusable and to wrap routines that are commonly called in ASP applications. It is true that ASP scripts can also be reusable; however, this requires copying and pasting the script and duplicating it in all the documents that need its functionality. This means that if the code needs to change, the change then needs to be propagated to all the pages that use the code. In contrast, reusable code is more easily and efficiently managed through components. All ASP applications can access a single physical component. And when that component needs to be modified or revised, the change needs to be made in just a single place. So for code that needs to be reusable, an ASP component is a better choice than ASP scripting.

ASP components can be used to modularize an application, splitting off discrete, manageable bits of functionality that can then be coded by several people in parallel or even purchased from some other party. An additional advantage to modularization of code in components is that the components can themselves be distributed on different machines, and component access can be handled remotely through DCOM or some other equivalent technology. This approach ensures that the application is more scalable and will be able to handle increasingly larger numbers of accesses. If the ASP components are also configured and coded as MTS components, transaction management for all of the components can be handled directly by the Distributed Transaction Controller (DTC) regardless of where the component resides. Though transactions can be used with scripting, and ASP pages can be located on other machines, the management of doing both with pages containing straight scripting blocks instead of components can become more complicated.

If an organization is considering building an n-tier application rather than fitting within the traditional client-server paradigm, ASP components are an excellent tool to use to implement one or more of the application layers. A classic approach is to implement the business layer of an ASP application as one or more ASP components, and to handle the presentation layer in the web page using HTML and client-side scripting, including the newer Dynamic HTML (DHTML). The data access layer would be contained within the database used in the application.

Finally, ASP components are a handy way of ensuring uniformity of an application. For example, if database queries are formatted for output into HTML tables with a certain look, the data presentation functionality can be maintained within ASP components in a layer between the web pages and the business logic, and used for all database queries.

Once sold on using ASP components, as I hope you are, the next choice is the tool or language to use.

Choosing the Language: Java, C++, or Visual Basic

In actuality, there is no "right" tool or language to use for writing ASP components. Any tool capable of creating in-process COM objects can be used to create ASP components. This includes Visual C++, Visual J++, and Visual Basic from Microsoft. This also includes Delphi from Inprise (formerly Borland), PowerBuilder from Sybase, and a host of other tools. However, if a company has chosen ASP as an application development environment, it is more likely that the company is using a Microsoft tool for developing the components, which is why this book covers writing ASP components using the Microsoft tools.

NOTE:  

Though this book covers Microsoft tools, the technologies and the samples, though not necessarily the framework or the step-by-step instructions, can be used with any C++ tool that supports COM or, like C++Builder from Inprise, that supports the use of ATL. The same applies to Java; if a tool supports the new Java WFC classes and Java-wrapped COM access, and can run with Microsoft's Java VM, it can be used to develop ASP components that work with IIS.

As for which language to write the component in, there is no one choice that stands out clearly over the others. Writing ASP components using Visual Basic exposes less of the underlying functionality than writing the same component using Visual J++ or Visual C++. Because of this, Visual Basic is the easiest tool to use, particularly for a shop that has primarily used tools such as PowerBuilder or Visual Basic for most application development. If a shop is porting a traditional Visual Basic client-server application to an n-tier system, the continued use of Visual Basic also makes sense. Chapter 9, Creating VB Data Access Components, and Chapter 10, Creating N-Tier ASP Components Using Visual Basic, provide coverage of writing ASP components for this type of environment.

However, for a Java shop, it makes no sense to switch to Visual Basic when using Visual J++ or a comparable Java-based development tool is just as effective. Microsoft has provided a set of Java wrappers for the ASP built-in objects, and Visual J++ handles all COM interfaces automatically. The main concern of a Java developer writing ASP components is to ensure that all data types used for parameters are CORBA-compliant, which also makes them relatively safe for COM. Chapter 15, Creating a Simple Java Component, covers the Java/COM concerns, and Chapter 16, The Java Interfaces, discusses how to access the built-in ASP objects. In particular, Chapter 18, Java ASP Components and J/Direct, Native Code, and Marshaling, covers native API access, which could be important for some of the components you might develop.

NOTE:  

At the time of this writing, Microsoft is being sued for its extensions to the Java language. Wherever possible, notes are inserted into the Java chapters that detail what may or may not change based on the outcome of this lawsuit.

Visual C++ exposes more of an ASP component's underlying COM architecture and can be used to create the most efficient and speedy components. However, that same exposure to COM also makes using Visual C++ a more difficult choice. If the shop creating the components has no C++ or Visual C++ experience, this approach becomes prohibitive. However, if a shop has used Visual C++, then Microsoft has provided the ActiveX Template Library (ATL) to assist in implementing ASP components; it handles almost all of the details associated with the implementation of a COM component. Using ATL and accessing the ASP built-in objects are covered in Chapter 11, Creating a Simple C++ ASP Component, and Chapter 12, The C++ ASP Built-in Interfaces. In addition, Chapter 14, Persistence with ASP Components Using ATL and MFC, also provides coverage of file I/O in addition to serializing information for persistence beyond the life span of an ASP application.

As for concerns about interoperability, considering that ASP components are COM components, they are by their very nature interoperable within a COM environment. Even within an organization that uses CORBA rather than COM, there are COM-to-CORBA bridges to handle communication between the two component management/communication approaches.

The underlying language used to create the component does not matter because ASP components are based on a binary interface, not a language-specific interface. This does, however, limit their portability to only those systems that have COM support.

NOTE:  

Needing COM and working with ASP does not necessarily mean that an ASP component will only reside on a Windows NT or 9X platform. Chili!Soft has implemented a product called Chili!ASP to process ASP pages from servers such as Netscape, including Netscape running on a Unix box. See the Chili!Soft web site at http://www.chilisoft.com/ for more information. In addition, Software AG, with a web site at http://www.softwareag.co.uk/, has ported DCOM to Unix, and there is an interesting article on building COM components on Unix at http://msdn.microsoft.com/developer/news/feature/vcjune98/unixcom.htm.

Integrating MTS with ASP Components

MTS is a component/transaction management system that can be used to register components, package them for transportation and installation, expose the objects for remote client access, and work with the DTC to actually manage transactions. In addition, MTS also provides support for stateless components and resource pooling, concepts discussed in this section, as well as in Chapter 5, Components, Transactions, and the Microsoft Transaction Server.

<ASP: What It Is and How It Works

Transaction Management>


To Purchase: Click Here>>>>


[print version of this page]

Of Interest
· Discussion Board