Web-службы

Тема 7. «Web службы и технологии промежуточного
уровня»
Цель
Рассмотреть преимущества вынесения прикладной логики на
промежуточный уровень приложения.
Задачи
1. Понять место и роль промежуточного уровня архитектуры
приложения.
2. Изучить технологию создания повторно используемых
компонентов промежуточного уровня – уровня взаимодействия
приложения с обрабатываемыми данными.
3. Познакомиться с технологией доступа к объектам с помощью
Web-служб.
Оглавление
Место и роль промежуточного уровня в многоуровневой архитектуре
информационной системы
Определение промежуточного уровня
Преимущества среднего яруса
Повторное использование
Применение промежуточного уровня для презентационной логики
Web-службы
Выводы
Вопросы для самопроверки
Литература
Место и роль промежуточного уровня в многоуровневой
архитектуре информационной системы
Традиционная
архитектура
«клиент-сервер»
предполагала
размещение прикладной логики непосредственно в модуле
программного приложения, а хранение данных – в базе данных.
Современная концепция построения распределенных приложений
использует многоуровневую архитектуру (рис. 7.1), в которой
различают уровень представлений (презентаций), промежуточный
уровень (деловой, средний – другие названия этого уровня) и уровень
данных.
Наиболее актуальной является сегодня организация системы, при
которой прикладная логика находится на промежуточном уровне или
распределена среди нескольких уровней.
Роль уровня представлений в этом случае состоит в том, чтобы
служить внешним лицом приложения. В последнее время уровень
представлений все больше и больше становится ориентированным на
web.
Уровень данных позволяет получать и передавать данные в
хранилища данных. Эффективный уровень данных помогает среднему
уровню выполнять доступ к базе данных.
Уровень презентаций
Web-формы
Windows-формы
Набор данных
Набор данных
Уровень Интернет/Интранет
XML
Промежуточный (деловой) уровень
Адаптер данных
Соединение с базой
данных
Уровень данных
Servers
Рис. 7.1. Многоуровневая архитектура информационной системы
В
n-ярусных1
системах
прикладная
логика
предоставляет
пользователю все необходимые данные и службы, но полностью
скрыта от него.
Определение промежуточного уровня
Промежуточный уровень или средний ярус – это логический слой в
распределенной системе, находящийся между UI (User Interface –
интерфейс клиента) и DAL (Data Application Layer – слой доступа к
данным). Обычно средний ярус содержит функциональность и логику,
необходимые для определения назначения и работы системы.
Другими словами, средний ярус является коллекцией правил,
объектов и функций, которые генерируют и оперируют с данными для
выполнения задач системы.
Средний ярус обычно является тем местом, где исполняется основная
логика приложения. Так как все системы логически различны, средний
ярус может принимать совершенно разные формы. В системе, которая
должна помещать данные в базу данных и извлекать их из нее,
средний ярус может быть очень простым. В приложениях,
1
Так принято называть распределенные приложения с архитектурой, показанной на рис. 7.1.
насыщенных сложными вычислениями, средний ярус обычно отвечает
за выполнение этих вычислений и применения логики приложения.
Наличие такого большого количества различных архитектур среднего
яруса представляет разработчикам огромные возможности для
творческого проектирования и планирования систем.
Преимущества среднего яруса
Общим
для
n-ярусных
архитектур
является
способность
предоставлять абстракцию для яруса, лежащего выше. Например,
ярус данных инкапсулирует логику доступа к данным в наборе
объектов, отвечающих за коммуникацию с хранилищем данных. Имея
готовый уровень доступа к данным (DAL), разработчик среднего яруса
освобождается от необходимости понимать то, как реализован код
взаимодействия с базой данных. На самом деле, разработчику
среднего яруса не требуется понимать архитектуру базы данных во
всех ее деталях.
Разработка среднего яруса дает абстракции для разработчиков,
работающих над уровнем презентаций (UI). Как мы не хотим
требовать от разработчиков среднего яруса понимания логики базы
данных, так мы не хотим требовать от разработчиков UI работы с
логикой приложения. Разработчики презентационного уровня (UI)
должны озаботить себя изучением только интерфейса (API –
Application Program Interface) среднего яруса.
Повторное использование
Разработка разделенной на ярусы системы предоставляет
возможность повторного использования программных компонент на
каждом ярусе. На слое среднего яруса мы отделяем код логики от
кода интерфейса клиента (UI). Абстракция позволяет нам реализовать
множество клиентских частей с использованием одного и того же
набора логики среднего яруса.
Повторное использование также возможно при использовании одного
и того же UI. Если у нас есть набор часто используемых программных
компонент, то выделение их в логику среднего яруса позволяет нам
снова использовать их в различных частях приложения.
Наиболее
распространенным
примером
частого
повторного
использования кода являются объявления объектов Connection и
Command, которые принимают строку подключения и запрос и
возвращают результирующий набор записей. Эту логику можно
упаковать в виде функции, принимающей в качестве параметров
строку подключения и запрос, а возвращающей результирующий
набор записей.
В программном коде, приведенном ниже, показан простой пример
использования промежуточного уровня для подключения к базе
данных, выполнения запроса и возвращения объекта в виде HTML-
таблицы. Этот код никак не влияет на возвращаемые данные, а только
отображает их.
На самом деле запрос выполняется в базе данных. Обратите
внимание
на
использование
хранимой
процедуры
dbo.StoredProcedure1, которая является типичным примером
размещения прикладной логики на уровне данных приложения. Такое
расположение программного кода удобно потому, что код,
размещенный на сервере баз данных, компилируется для наиболее
эффективного вычисления сервером. То есть, в результате, хранимая
процедура, которая располагается на уровне данных, будет
выполнена быстрее, чем хранимая процедура, которая располагается
на промежуточном уровне.
Private Sub Изменение_Цены_Товара(ByVal str String, ByVal x As
Double)
Dim cmd As New SqlCommand
Dim cnn As New SqlConnection
cnn.ConnectionString = "str"
TextBox1.Clear()
cmd.Connection = cnn
cmd.CommandType = CommandType.StoredProcedure
cmd.CommandText = "dbo.StoredProcedure1"
Dim p As New SqlClient.SqlParameter("@par", x)
p.SqlDbType = SqlDbType.Float
cmd.Parameters.Add(p)
cnn.Open()
Dim dr As SqlDataReader=cmd.ExecuteReader()
Do while dr.Read
Response.Write(dr.GetInteger(0))
Response.Write(“&nbsp” & dr.GetString(1))
Response.Write(“”&nbsp” & dr.GetString(2))
Loop
cnn.Close()
End Sub
Таким образом, вся логика вычислений была распределена между
двумя уровнями: средним уровнем и уровнем данных. Теоретически
этот способ выглядит очень привлекательно, но в реальной ситуации
возникают проблемы с контролем версий, удаленным доступом и так
далее. В течении длительного времени такой подход реализовывался,
например, на языке С++. Язык С++ и подобные ему языки
традиционно имели доступ к низкоуровневым функциям компьютера,
чего были лишены многие другие высокоуровневые языки
программирования.
Появление концепции .NET Framework внесло серьезные изменения в
этом вопросе. Для всех языков, поддерживающих .NET, открыты
низкоуровневые библиотеки в среде разработки Visual Studio.NET.
На конкретных практических примерах рассмотрим применение
промежуточного уровня для реализации презентационной логики.
Применение промежуточного уровня для презентационной
логики
Рассмотрим создание простого запроса в виде повторно
используемого
объекта.
Основная
цель
примера
–
продемонстрировать способ создания функции в одном месте и
использование ее сразу в нескольких приложениях. Другими словами,
мы должны рассмотреть технологию создания повторно используемых
компонентов промежуточного уровня.
Создание нового компонента выполняется или в рамках одного из
имеющихся проектов, или создается новый проект (Windows или Web
Application). Компонент не имеет собственного интерфейса, поэтому
после добавления в проект формы для компонента (Add-Add
Component) следует сразу перейти в область кодирования. Так же, как
и для обычного приложения следует выполнить импортирование
требуемых пространств имен и ввести программный код функции или
процедуры, например, такой:
Imports System.Data, System.Data.SqlClient
Public Class GetRowCount
Inherits System.ComponentModel.Component
Public Function GetRowCount() As Integer
Dim
cnnStr
As
Stringr="server=(local);database=EmployeeInfo;
TRUSTED_CONNECTION=Yes"
Dim cnn As New SqlConnection(cnnStr)
Dim cmd As New SqlCommand("SELECT COUNT(*) FROM Employees",
cnn)
cnn.Open()
Dim dr As SqlDataReader = cmd.ExecuteReader(
CommandBehavior.CloseConnection)
Do While dr.Read
GetRowCount = dr.GetValue(0)
Loop
dr.Close()
cnn.Close()
End Function
End Class
Использовать созданный компонент, возможно, прежде всего, в
текущем приложении, но можно использовать его в любом другом
Windows или Web приложении.
Для указания ссылки на внешний компонент в любом другом проекте
следует в окне Solution Explorer проекта выбрать в контекстном меню
команду Add Reference и указать путь до вашего компонента. В
программном коде формы, которая будет использовать ваш внешний
компонент необходимо импортировать пространства имен и далее
обращаться к компоненту, вызывая его методы:
Imports Имя_приложения_с_компонентом.GetRowCount
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Dim GRC As New GetRowCount
Response.Write(GRC.GetRowCount.ToString)‘ Response – объект,
который используется для пересылки информации от сервера
клиенту. Является экземпляром класса HttpResponse и возвращается
свойством Response загружаемой страницы (Page), ссылка на которую
подразумевается по умолчанию.
GRC.Dispose()
End Sub
Web-службы
С самого начала Web-среда рассматривалась как способ передачи
данных между двумя точками. Именно эта исходная концепция
способствовала развитию и популяризации Web-среды. Однако Webсреда обладала несколькими ограничениями и только недавно
консорциум World Wide Web Consortium (W3C) начал реализовывать
стандарты технологии обмена данными. Реализация Web-служб на
платформе .NET основана именно на этих стандартах и использует
язык XML для идентификации и передачи данных.
Предположим, что некая компания решила предоставить другим
компаниям быстрый доступ к своим данным без необходимости
создания пользовательского интерфейса. Для решения этой задачи
прекрасно подходят Web-службы.
По определению Web-службы – это объекты, которые обмениваются
данными с помощью протоколов Internet, например HTTP. Причем для
определения данных или набора выполняемых сервером инструкций
используется XML. Эти инструкции также могут возвращать данные.
Например, для включения нового пользователя с фамилией
Табуреткин и именем Федор в базу данных можно послать некоему
воображаемому Web-серверу www.someserver.com следующий
запрос:
http://www.someserver.com/sevices/dataserver.asm?op=
AddUserToDB&FName= Табуреткин&Lname= Федор
В данном примере используется протокол HTTP и запрос GET для
вызова службы dataserver, которая имеет функцию AddUserTiDB с
двумя параметрами – FName и LName. Было бы совсем неплохо, если
бы Web-служба информировала нас об успешности добавления
указанных данных в базу данных. Фирма Microsoft совместно с
несколькими другими компаниями предусмотрела реализацию таких
возможностей и разработала язык определения Web-служб Web
Services Description Language (WSDL). WSDL способен анализировать
код Web-службы и находить ту информацию, которую нужно сообщить
пользователю о данной Web-службе и выполняемых ею функциях.
Пример такого сообщения вы увидите ниже (рис. 7.3).
Как уже отмечалось, доступ к Web-службе осуществляется с помощью
HTTP-протокола (методы GET и POST). Кроме того, для
взаимодействия Web-служб разработан протокол объектного доступа
Simple Object Access Protocol (SOAP), который позволяет Webсерверам обмениваться сообщениями с инструкциями запросов,
заключенных в конверт (envelope).
Рассмотрим конкретную бизнес ситуацию, для решения которой
следовало бы применить Web-службы.
Система учета заказов должна осуществлять несколько проверок.
Например, если делается зарубежный заказ, то стоимости доставки
должна быть учтена в стоимости заказа, или, если заказ выполняется
в выходные дни, то это также изменит стоимость заказа и так далее.
Web-службы дают разработчику возможность публиковать свои
функции в Web-среде (Internet) или корпоративной среде (intranet),
которые входят в состав других приложений или баз данных и
располагаются на том же или на другом компьютере, о которых
разработчик может даже не подозревать. Web-службу можно вызвать
с любого компьютера, подключенного к Internet или внутренней сети
под управлением операционной системы.
Создание простой Web-службы аналогично созданию класса.
Различие между классом и Web-службой состоит в том, что методы
Web-службы должны иметь атрибут WebServiceAttribute. Этот атрибут
говорит о том, что среде выполнения следует открыть доступ к этому
методу как части службы. Без этого атрибута метод не будет открыт
для доступа.
Используя возможности Visual Studio.NET и шаблон для новой Webслужбы создаем Web-службу для вычисления окончательной
стоимости заказа с учетом всех условий:
Imports System.Web.Services
<WebMethod()> Public Function CalculateItem(ByVal Cost As Single,
ByVal TaxCode As Integer) As Single
Console.WriteLine("Сумма вычислена:")
Select Case TaxCode
Case 0
CalculateItem = Cost
Case 1
CalculateItem = Cost * 1.06
Case 2
CalculateItem = Cost * 1.12
End Select
End Function
Код довольно условный, следует обратить внимание на следующие
позиции. Перед описанием метода используется ключевой оператор
<WebMethod()>, а также импортирование пространства имен
System.Web.Services.
После написания кода Web-сервиса следует стандартный процесс
компиляции решения (Solution Explorer-Build). Вот собственно и все,
Web служба готова к работе, графический интерфейс ей не нужен.
Теперь после размещения этого кода на открытом Web-сервере
любой пользователь может с помощью Web-браузера открыть данную
Web-страницу и выполнить указанный метод. Обычно эта цель
достигается программными средствами, а не вручную. Рассмотрим
пример такой ситуации.
Создадим консольное приложение (можно было построить Windows
или Web-приложения, но не будем усложнять наш пример), которое
позволит осуществить доступ к нашей Web-службе (тестирование).
Учтите, что основные принципы доступа к Web-службе остаются
одинаковыми независимо от типа проекта.
Для соединения с Web-службой (из проекта любого типа) нужно
создать Web-ссылку (Solution Explorer-Add Web Reference). На экране
появится диалоговое окно Add Web Reference (рис. 7.2). Следует
указать в поле Address URL-указатель используемой Web-службы.
После этого в диалоговом окне Add Web Reference сразу же появится
описание Web-службы и список ее методов.
Рис.7.2. Диалоговое окно добавления Web-ссылки на Web-сервис
Такой результат получается благодаря языку WSDL, который
вставляет метаданные с описанием Web-службы в ее код.
Для добавления в проект ссылки на выбранную Web-службу следует
нажать кнопку Add Reference.
Но не торопитесь сразу нажимать кнопку Add Reference, так как
выполнить тестирование Web-службы можно непосредственно и в
текущем окне диалога. Для этого следует щелкнуть мышью на
названии метода Web-службы – CalculateItem (рис. 7.3), ввести
конкретные значения параметров метода, нажать кнопку Invoke и
просмотреть результат работы Web-службы в окне Explorer в формате
XML (рис. 7.4).
Рис. 7.3. Диалоговое окно Add Web Reference
Рис. 7.4. Ответ web-службы в формате XML
Само консольное приложение также можно использовать для доступа
к методам Web-службы. Чтобы протестировать созданную нами Web
службу можно ввести в консольном приложении программный код для
вывода результатов работы службы (рис. 7.5).
Imports System.IO
Module Module1
Sub Main()
Dim AAA As New localhost3.Order
System.Console.WriteLine(AAA.CalculateItem(100, 2).ToString)
AAA.Dispose()
End Sub
End Module
Рис. 7.5. Консольное приложение для доступа к Web-службе
Выводы
Промежуточный уровень в архитектуре приложения – это то место,
где исполняется большая часть логики приложения. Были описаны
способы организации и реализации промежуточного уровня для
повышения
производительности
приложения
и
повторного
использования кода.
Физический промежуточный уровень (средний ярус) – это аппаратная
архитектура, на которой развертывается средний ярус. Средний ярус
может находиться на той же физической машине, что и другие ярусы
нашего приложения, или быть развернут на отдельной машине или
наборе машин. В приложениях с большим количеством клиентов,
зависящих от логики среднего яруса, создание физического среднего
яруса дает нам много преимуществ, включая упрощенное
развертывание, интеграцию и возможность проведения обновлений.
Web-службы, основанные на наборе открытых технологий, включая
SOAP, WSDL и XML, предоставили механизмы для вызова удаленных
процедур. Было продемонстрировано, как повторно используемый
компонент можно применить с помощью Web-службы практически в
любом приложении.
Средний ярус с точки зрения логики является наиболее интересной
частью приложения. Используя правильные методы проектирования,
и понимая базовую функциональность, предоставляемую .NET, мы
можем создавать очень эффективный средний ярус, который может
повторно
использоваться
большим
количеством
клиентских
приложений, как имеющих GUI (ASP.NET и формы Windows), так и не
имеющих такого графического интерфейса (удаленный доступ и Webслужбы).
Вопросы для самопроверки
1. Что такое n-уровневая архитектура приложения? Какие уровни
принято различать в архитектуре приложения?
2. Какие задачи при проектировании приложения можно выносить
для решения на промежуточный уровень?
3. Какие компоненты можно размещать на промежуточном уровне
приложения?
4. Может ли программный компонент использовать возможности
промежуточного уровня и уровня данных одновременно?
5. В каких приложениях может быть использована Web служба?
6. Что такое Web-ссылка на Web-службу? Как создать подобную
ссылку?
7. Если Web-служба не имеет собственного интерфейса
пользователя и консольное приложение не имеет такого
интерфейса, то каким образом можно просмотреть результаты
выполнения Web-службы?
8. Является ли обязательным размещение Web-службы на
локальном сервере?
9. В случае размещения Web-службы на открытом web-сервере как
следует указывать имя для ссылки на Web-службу?
10.
Будет ли верным следующее утверждение: «web-служба –
это не что иное, как web-страница без графического интерфейса
пользователя»?
11.
Можно ли создать несколько методов аутентификации
доступа к web-службе на web-сервере?
Литература
1. Р.Бедвелл, О.Корнз, К.Гуд. Основы ASP.NET и VB.NET: Пер. с
англ. – М.: Издательский дом «ЛОРИ», 2006. – 569с, ил. – Парал.
тит англ.
2. Visual Basic .NET. Масштабируемость. Справочник / Практ.
пособие. / Пер. с англ. — М.: Издательство «СП ЭКОМ», 2006. –
432 с.:илл.
3. Эпплман Д. Переход на VB.NET: стратегии, концепции, код. —
СПб.: Питер, 2002. — 464 с.: ил.
4. Троелсен Э. C# и платформа .NET. Библиотека программиста —
СПб.: Питер, 2006 — 796 с.: ил.