/vnd/media/agency_attachments/bGjnvN2ncYDdhj74yP9p.png)
In
today’s world of complex businessinteractions, Net-based
transactions have almost become a bare necessity rather than a
luxury or an add-on package offered by the business
establishments. The challenges that lie ahead for a project
manager are in bringing all the complex operations of the
business to simple browser-based front-ends. Furthermore, he has
to not only ensure that the customers all around the world are
reached but also expose the ongoing transactions in a highly
controlled atmosphere to the WWW. And in a large-scale
enterprise, the challenges are much more acute and demanding for
him as in the back-end environment reside huge mainframes/legacy
systems and databases. Only a very careful analysis and
selection of the Net strategy, technology, design, and
architecture can make it possible.
The world of business
computing has long realized that the traditional
"monolithic" enterprise IT architectures are extremely
difficult to develop and maintain. And these have been moving
from a single-tier applications to two-tier and three-tier
applications. Two-tier architectures mostly adopt the
client/server architectural framework of distributed computing
and even now, many enterprises are successfully adopting this
framework for their computing requirements. But serious
limitations and problems come to light when such systems and
architectures are exposed to Net-based transactions. These
fundamental problems arise because of the fact that corporate IT
computing and Internet Web architectures have grown as two
independent streams of technology and nobody expected them to
meet each other and handshake.Â
What
Is the Solution?
Of late, enterprises and corporates have realized that there is
the need to formulate very strong and committed strategies for
their future Web-based business. It just may not be possible to
develop the contemporary systems right from the scratch
exclusively for the Net. And it may be too late before things
"really" start working. So, the need of the hour is a
strategy that ports or "exposes" the existing systems
to WWW in a very safe and healthy manner. In such a transition,
a very safe, controllable, and maintainable corporate
environment is suddenly exposed to the world of one million hits
a day, hacking, and security leaks and the traditional two-tier
architecture simply crashes in such a demanding situation.
The question that arises
is if e-commerce is prone to such serious threats and
limitations, does it have to learn to live with it? It need not
in the world of multi-tiered computing architecture, enterprise
Java, and Web application servers. There are a brand new set of
strategies and technologies that can bring e-commerce close to
implementation in large-scale enterprises. The most interesting
part of these hitherto unknown ways of building systems is that
they allow your existing systems to migrate to WWW with little
or no effort. They also give a very clear-cut direction to the
enterprise computing efforts that can adopt themselves to all
future developments, so that they are compliant with the
requirements of the Net, apart from their own organizational
needs. All of these strategies when, combined and adopted in the
right proportions for Internet-based business requirements, the
miracle just starts working.
All Clients Are Not Trusted
The first step in this direction would be to relieve the
client terminals of all complex and simple business tasks–call
them "thin clients" if you want–and make them almost
dumb. Does it not mean wastage of immense computing power that
is available at the client’s end? Yes, it does. However, it
needs to be remembered that in Internet the clients are not only
one’s old colleagues who wish you every morning, but all those
unemployed but big brain nerds who are constantly exploring and
inventing newer possibilities of cracking down a customer’s
secret account number passed via a URL. This "dumb"
client will not be anything more that a simple "HTML"
page with the required information and presentation graphics.
The embedded scripting language may do some minor checks and
validations, but not any of the business transactions. This is
the very strict first rule in this new e-commerce-based
enterprise computing strategy–assume that all clients are not
trusted.
It is obvious that while
implementing this, there can be various levels of exposing
between an unknown Web client and a well-known corporate
employee–and the degree of trust you place upon them can
gradually increase. A corporate employee may be granted more
rights that the former.
Enter Web
Application Servers
What happens to the business transactions that were conducted in
the client’s end in the above situation? Are we to move
everything to the server side? Certainly not. The real heroes
behind today’s most successful e-commerce enterprise solutions
(some vendors do not hesitate to call them e-commerce servers!)
are a new breed of servers that have little similarities to the
earlier varieties of servers we are familiar with. Of course,
they do cognate with the Transaction Processing Monitors (TP
Monitors) of the mainframe-computing world in some core
respects. But experts deem it a sin if you call these classes of
servers by the same name. So, where does this new class of
servers fit in large-scale enterprise architecture and at what
tier? Below the "thin HTML clients" there has to be
obviously a Net Server to attend to the HTTP requests. So,
applications servers can come only below this.
Databases and
Legacy Systems in the Last Tier
The databases, legacy systems, and other heavyweight back-end
systems have been pushed to the last tier. (Refer a typical
three-tier enterprise IT architecture in the figure. Though only
three tiers have been shown, during actual implementation, each
tier may be sub-divided. So, strictly speaking, it will be a
multi-tiered architecture).
an Application Server
What goes inside the application server, after all? It must be
remembered that the aim was to "port" existing
large-scale applications and enterprise systems to WWW while
exercising absolute control in doing so. These old systems do
not necessarily posses certain "qualities" like load
balancing, scalability, and security that are imperative to the
simplest e-commerce transaction. Worse still, there are no short
cuts to inject these qualities into the existing systems so that
they become "Net Ready". So we are left with no other
alternative, but to hide all these complex enterprise systems
behind a safe, secure, and e-commerce oriented transaction
system that will do all the communications with the back-end
systems on the client’s behalf, get the results, and convey
them back to the client. That is exactly the core task of an
application server.
An application server sits
between the Internet servers and back-end systems and
streamlines the transactions between them. It contains one or
more of "business logic components" that actually
expose a set of well-defined services to the outside client (in
our case, the Internet server). Besides, it takes up the
responsibility of communicating with the back-end systems and
see to it that the requested task is completed safely and the
results are sent back.
All the demanding
requirements of e-commerce business system are inherent to these
application server architectures and the business components
that start their lives inside them generally inherit all these
qualities and get ready to face the challenges of complex
e-commerce transactions. Application servers very carefully
manage the available resources on either end so that the
requested transactions can be completed efficiently, within the
shortest possible time.
Consider a very busy
banking web site, requesting for different kinds of services in
a common portal! It becomes the sole responsibility of the
application servers to see to it that all these requests are
handled properly within reasonable time. No client will be
patient enough to wait even for a few minutes! (Somehow, he
forgets the time he used to spend for a similar transaction in
the very same bank!).
It is here that terms like
"scalability" and "load balancing" enter the
picture. These are the abilities of the Web application server
to "scale" and meet the increasing number of client
requests at any point of time. In typical situations,
application servers actually sit over not one, but several
servers that are "clustered together" and make them
available as a single resource pool. The application servers
also take the responsibility of shifting the loads to other
clusters in case a particular cluster gets "weakened"
because of one or more server failures.
Servers Limit Themselves to Web-based Clients Alone?
A very pertinent question at this juncture. The answer is–certainly
not. As we conceive the business systems of the near future, we
tend to think of a "streamlined flow" of requests from
a variety of clients. The clients would include not only
Web-based, but also all others like native window applications,
intranet clients, and even intelligent hand-held devices and
palmtops, passing through a common gateway.
The application server
architects claim that application servers have been built in
such a way that they can listen to requests from a variety of
clients originating from a host of newer technologies. And now
the stress is on "how open application servers are" so
that we can easily add additional functionality to the core pool
of available services, thus extending the server functionality.
Inserting Web
Application Server in Enterprise Architecture
How difficult is it to implement the new tier? It all depends
upon the existing architecture of the enterprise’s core
applications–database and system structures–and how far it
needs to be exposed to the Net. If the enterprise has already
adopted itself to object-oriented or components-based approach
to its native software solutions, then the migration can be
expected to be relatively less painful. But with all mainframes
and Cobol still in place in large-scale enterprises, it needs
more than a sincere effort for the new environmental migration.
A recent trend, noteworthy
to mention here, is the strategy of some of the leading players
to bundle their application servers with a host of "common
e-business components" like customer profiling, billing,
and shopping carts so that you can get started right from day
one. Some offer these business components that are specific to
the business one is in. For example, there are vendors who offer
specialized banking-related components, along with their
products. It is advisable to give all these "bundled"
components a closer look and decide that they are extensible
enough to be adapted to your specific business needs.
Some application servers
offer Integrated Development Environment (IDE) that makes
developing applications and components for the server
environment a lot simpler. Ultimately, whatever may be the
strengths of the application servers one chooses, he must be
able to tap that potential easily into his applications and his
development team should be able to achieve productivity, while
working at ease. IDEs are very important in this respect. All
application server vendors have started attaching lot of
importance to this generally overlooked issue so as to win the
vote of the actual programmers, involved in the development
processes. For example, IBM brings its Web Sphere Application
Server environment right into its Java development platform
called Visual Age. Symantec’s Visual Café—another popular
IDE for Java development environment–has been recently
purchased by another application server vendor.
Application Servers Available in Many Flavours
As one sets forth to actually identify a particular application
server for his or her requirements, he/she will simply be
astonished by the varieties in which they are currently
available (not considering newer products introduced every day).
Almost all big players have entered this lucrative market that
is poised to grow by many billions in the near future. Just have
a look at this list: Apple’s Web Objects, Bluestone
Sapphire/Web, BEA Weblogic, IBM Websphere, Sun Netdynamics,
Sybase Enterprise Application Server, Oracle Application Server,
Sun-Netscape’s Iplanet, Lotus Domino The choice is not at all
easy.
The business and
technological backgrounds of these players do play a role in
influencing the decision to adopt a particular application
server. For example, if your enterprise has rigorously adopted a
particular database from a vendor for all of your systems and if
you find the same vendor offering his own application server,
then, most probably you can expect a native built in support for
that database in their application server. This is
understandable, as every vendor wants to support his other own
products a step ahead of all others.
This may or may not be a
critical issue since some standards are luckily in place. For
example, the very same application server is likely to support
all ODBC or JDBC connectivity. So theoretically one can connect
the server to any other database using the relevant drivers.
All said and done, for all
these application servers and the associated e-commerce
applications to evolve and succeed in a demanding global
business scenario, it is essential that certain commonly agreed
upon standards are evolved and strictly adopted across the
globe. Unfortunately, the pandemonium that usually exists in the
IT world when it comes to ‘standards’ has made an indelible
scar even on the face of application server scenario.
Of late, the Java 2
Platform, Enterprise Edition with its very attractive options
like Enterprise Java Beans (EJBs), Java Server Pages (JSPs) and
Servlets, backed by the power of Java itself as a very strong,
platform-independent server side language, seems to emerge as
the de facto standard. But considering the muscle power of
Microsoft which is pushing its COM/DCOM standards and Microsoft
Transaction Server as an alternative to EJB and J2EE based
servers, and its loyal user base all across the globe, it may
take time for the users to decide upon their choice and adopt
themselves to the winning standards that will emerge.