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 Altova MissionKit, recent winner of the Jolt Product Excellence and Productivity Award for Best Development Environment,
is an integrated suite of tools ideal for:
- XML development
- Web & Web services development
- Data mapping & integration
- Rendering & publishing XML & database data
- XBRL validation, taxonomy editing, transformation & rendering
The MissionKit for XML Developers includes XMLSpy®, MapForce®, and StyleVision® plus 3 additional tools for less than the price of 2.
Try all 6 products free for 30 days!
Download a fully-functional free trial
|
|
|
| 
