Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


Tip of the Day
Language: Web Development
Expertise: Beginner
Oct 1, 1998

Technologies and Choices When Building a Web App

Question:
We are trying to develop an intranet application and have traversed many rough roads and dead ends. Our environment is Internet Explorer 4.0 (some IE3), SQL Server 6.5 (soon to be 7.0), Windows 95 and NT 4.0 clients (mostly 95), and Internet Information Server (IIS) 4.0 at our end. One major problem is that our company has strangled Win95/IE4 with all kinds of restrictions (registry modifications and adding OCXs are a hassle, and we have just convinced them to move the IE4 security model from high to medium). We develop in Visual Basic 5.0 (now VB6) and Front Page 98.

Where can we find out the plusses and minuses of the different avenues of development open to us? I can read all about how great Microsoft Transaction Server (MTS) is, but can go somewhere else to find out that their alternative is great too. Trouble is, nothing compares the different technologies and offers a decision base as to why you'd choose one over the other. Can you help, or point us to some help? Thank you.

Answer:
I have heard comments similar to yours from other developers around the country. They tell me about how their company network is locked down tight by their company's systems group and they feel powerless to implement technologies involving new technologies. After all, how can you build software that is as powerful and robust as possible if your company restricts the technologies that you are allowed to use?

It is a scenario that is more common than you might think. My personal opinion is that developers should be allowed to "push the technology envelope"...but of course, that is from my biased, developer-based perspective.

On the other side of the equation is your systems group. Just as a developer's job is to create software, the job of the systems group is to keep the network, and all the machines on the network, up and running smoothly. Anytime machines go down, or the network goes down, the systems group is in hot water. To avoid this situation, the system's group typically will restrict what can be done on the network and on machines on the network. You can see the obvious dichotomy. Your job is to build robust solutions with the best and most powerful (usually newest) technologies available...their job is to maintain stability, peace, and harmony on the network. Of course you are going to have conflict!

Part of your job as a developer (whether you know it or not) is to convince the system's group that it is in their best interest to allow you to explore these new technologies. For example, you might demonstrate how Microsoft Transaction Server can help reduce network traffic and ease the resource burden on application servers. That will make the system's group happy.

In addition to that, I am a strong believer in providing developers with their own "scratch" networks that can be used to test new technologies and "push the envelope" of what is available without worrying about disrupting the corporate network. It is understood that this entire sub-network will be reinstalled periodically. You would need a way to automate this process. The technologies and code that fall out of that sub-environment and appear to be robust and stable can be integrated into the corporate network as part of application solutions.

From the products that you mentioned, it sounds as if you are a "Microsoft Shop." As a result, it's probably a good idea to maintain that track in order maximize your chances of products working together. We all know what a problem that can be.

Microsoft offers two main technologies that can be used for building Web applications: Active Server Pages/Visual InterDev and Visual Basic 6.0 IIS Applications.

The reasons why you would use VB6 to build a Web application as opposed to Visual InterDev come down largely to personal preference. VB6 IIS applications came about due largely to the fact that many VB developers would rather use a tool that they already know and are comfortable with to build Web applications. With Visual InterDev, developers had to learn a new tool and a new programming model.

More specifically, the differences between the two types of projects come down to the type of developer that will use IIS applications and how code is separated from content. IIS applications will be used by VB developers who know and are comfortable with VB. Visual InterDev will be used by HTML and script writers. Using a VB6 IIS application, your HTML is stored in one file and your VB code is stored someplace else. In an InterDev application, VBScript is intermingled with HTML in the same file. In other words, VB6 can help you separate "presentation" from "content." InterDev applications do not separate "presentation" from "content" so cleanly. The question is: "How important is that to you?" Some people feel very strongly that "presentation" should be separated from "content." Others don't. For example, the W3C rejected Microsoft's tag simply because it didn't separate "presentation" from "content." That decision says to me that the idea is at least marginally important.

You can go ahead and start developing VB6 IIS applications today. It is a robust technology that you can use to perform all of the actions that you can perform in an InterDev application. This includes using server-side ActiveX components, client-side ActiveX controls and client-side script, among others. In addition, it has the added benefit of utilizing the familiar VB IDE and debugger. Despite the fact that Visual InterDev 6 now has a server-side debugger, VB's debugger is still better. This is powerful stuff!

Although, let me point out that IIS applications are a brand-new technology. The number of concurrent users an IIS application will support depends of course upon what the application does and the environment in which it runs. My advice is to do some stress testing in your environment.

The bottom line, VB6's Web application option is an attractive alternative for VB programmers.

Finally, let me address the question on whether or not to use Microsoft Transaction Server. Although MTS may seem to be a brand new product, it has been around, in one form or another for at least three years. It came about largely in response to critics deriding Windows NT's ability to support mission-critical applications with the same performance and reliability as UNIX systems. Because we know that Microsoft would like to see Windows NT become the de facto standard operating system for supporting mission-critical applications, we can be sure that it will pour resources into MTS to ensure that it runs reliably and does what it is supposed to do. In fact, MTS is so important to securing Windows NT's position as an Enterprise operating system that it will be integrated into the Windows NT 5.0 operating system. It will no longer be a separate product. So my answer is "yes"...learn it, know it, use it. MTS is an evolving technology, and just as all non-trivial software, it has its share of issues...but when all the players are performing optimally, it is the closest thing to magic I've ever seen.

DevX Pro
 

Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date