Applications must be Services
The paragraphs below describes W3Schools' vision about
future
Internet Distributed Applications.
Applications must be a Set of Services
Applications can no longer be allowed to contain large masses of compiled executable
code. Applications must be broken down into a number of smaller individual
services that are easier to create and easier to maintain.
Individual services should be developed and maintained by smaller groups of people.
Services are not the same as executables, or components, or DLL's. Services
should be answers to submitted requests. Services should be returned as data. Our best suggestion is to develop services as a number of
server-side HTML and/or XML pages.
Services must not be Purpose Built
Our history is full of applications that were purpose built for a single
task. Many of these applications died before they were introduced, because
they could not manage new changes in the requirements. This is a terrible waste
of money and time. We (and the people that pay for our applications) want to
create flexible applications that are so generalized that they can gracefully
support future changes. Future - not even thought about - changes should easily
hook into our application without crumbling or destroying it. Our best
suggestion is to create flexible standard services that can be used
to serve a lot of different requests.
Services must be easy to Create and Edit
Services should not be coded if it can be avoided. If a service has to be
coded, our best suggestion is to use scripts. Services should never be
compiled into executables. That makes services too hard to
access and to edit. Any pre-compiled component used in an application will threaten the possibility of creating
an application that can move, scale and gracefully
support future extensions or changes. Services should be created and modified by editing their properties and
methods, not by changing their executable code. Our best suggestion is to use an XML
editor to create and edit services, and to use a standard service engine to
provide services by executing the service description. The service descriptions
should be stored in a data store like a database or in an XML/HTML file.
Services and data must be Self Describing
Application clients must be able to query a server for a service and to ask for
the current server functions. Clients and servers must
also be able to exchange data in a way so that both understand
each element in the data. Our best suggestion is to use an XML based information
vocabulary with a DTD (Document Type Definition) to exchange server functions,
and to use XML to exchange data.
 |
 |
 |
 |
|
The Ektron Intranet
lets you do everything you need to do on your corporate intranet and everything you want to do... all with just one application.
What can you do with the Ektron Intranet? |
 |
Navigate through content, documents, assets, colleagues and workgroups quickly and intuitively with enterprise search |
 |
Communicate with friends and colleagues with forums, message boards and corporate blogging using the new Social Networking Platform |
|
Utilize the extensive out-of-the box features or customize your site through Ektron CMS400.NET's open architecture |
 |
Promote collaboration in your organization through project workspaces where others can efficiently find information and work together |
 |
Author/edit content, manage navigation, menus, audit trails, workflow and approvals with the best in breed Content Management |
|
|
|
|
See why there are 20,000+ Ektron integrations worldwide.
|
|
 |
TAKE THE VIDEO TOUR |
 |
or download a FREE TRIAL today. |
|
HOME
Printer friendly page
