Будущие приложения
Далее представленоПример версииО Будущих веб-приложениях.
Исполняемые файлы умрут, JavaScript выживет
Скомпилированные исполняемые файлы (например, скомпилированные из C или Java) не могут работать на разном оборудовании.
Исполняемые файлы (файлы EXE, объекты ActiveX и COM, файлы DLL) — это компоненты, которые препятствуют разработке приложений, работающих в Интернете.
Будущие приложения не смогут использовать компоненты, установленные на клиентских компьютерах, или полагаться на них.
Наше предложение:
Используйте только HTML, CSS и JavaScript для написания ваших будущих приложений.
Убедитесь, что ваши будущие приложения могут работать в любом веб-браузере.
Веб-приложения станут интернет-сервисами
Раньше приложения были большими и создавались для конкретных задач. Большинство из них вскоре умрёт, потому что они не могут предоставлять сервисы по мере изменения требований.
Приложения должны быть гибкими, универсальными и хорошо адаптироваться к изменяющимся требованиям без нарушения работы.
Приложения должны иметь возможность масштабироваться для поддержки миллионов запросов в день.
Приложения должны иметь возможность распределяться и перемещаться между несколькими серверами без нарушения работы.
Приложения должны иметь возможность работать вместе с другими приложениями.
Приложения не должны содержать больших объёмов кода. Приложения следует разбивать на более мелкие сервисы, чтобы их было легко создавать и легко сопровождать.
Приложение — это серия интернет-сервисов, которые возвращают данные в ответ на отправленные интернет-запросы.
Приложения должны запрашивать сервисы через стандартные интернет-протоколы, не поддерживая постоянное соединение с сервером.
Наше предложение:
Используйте Интернет на основе SOA (сервис-ориентированной архитектуры) для написания ваших будущих приложений.
Сделайте сервисы вашего приложения более универсальными, более гибкими и способными обслуживать разные типы запросов.
Будущие приложения будет легко создавать и редактировать
Клиентская и серверная стороны будут обмениваться данными понятным способом.
Приложения не будут программироваться, если этого можно избежать.
Приложения будут создаваться и изменяться путем редактирования моделей, а не редактирования кода.
Описания приложений будут удобочитаемыми для человека.
Описания приложений будут самоописывающими.
Приложения будут писать пользователи, а не программисты.
Наше предложение:
Используйте удобочитаемые для человека текстовые файлы для описания сервисов и предоставляйте сервисы путем выполнения этих описаний.
Используйте текстовые файлы (например, XML-файлы) для описания приложений.
Используйте текстовые файлы (например, XML-файлы) для обмена данными.
Используйте HTML, CSS и JavaScript для выполнения приложений.
Три маленьких веб-разработчика...
Жили-были три маленьких веб-разработчика, которые разрабатывали новый веб-сайт.
1. Первый веб-разработчик использовал <AppML>.
2. Второй веб-разработчик использовал свой любимый серверный язык программирования.
3. Третий использовал профессиональный корпоративный фреймворк для веб-разработки.
Первый веб-разработчик завершил демо за два дня. В сотрудничестве с пользователями начальный прототип был завершён в течение недели. После двух недель тестирования умный, быстрый и простой в использовании веб-сайт был готов к выпуску.
Шесть месяцев спустя второй веб-разработчик закончил работу над своим веб-сайтом. Но требования WWW изменились, поэтому он не был удовлетворён своим веб-сайтом. Этот веб-разработчик не мог внести существенные изменения в свой проект, потому что в нём было слишком много кода. Поэтому он начал разработку версии 2.
Третий веб-разработчик так и не смог успешно завершить свою работу. Тот профессиональный фреймворк для веб-разработки был сложен в использовании, труден для понимания, и его почти невозможно было тестировать.
Посмотрите, как это сделал первый разработчик.。
Другие расширения