Терминология Web-services
Начал копать Intalio|BMPS. Первое во что уперся измененный редактор рабочей версии 4.4 и текущей бетой 5.0. Некоторые обучающие материалы относятся к одной версии, другие к другой. Плюс отсутствие опыта разработки веб сервисов - пытаюсь приобрести знания и навыки...
В последнее время на работе также все крутится вокруг новой интеграционной платформы. И если на бизенс-уровне вроде бы все как и понятно, то на технологическом очередная "маленькая бездна"
Далее данные могут уже не соответствовать действительности, т.к. берутся из разных источников разного времени
Введение
Быстроразвивающиеся бизнес-отношения требовали, чтобы сетевые приложения, использующие различные протоколы, могли обмениваться между собой данными – таким образом, встала задача интеграции приложений.
На протяжении нескольких лет было создано несколько технологий взаимодействия распределенных приложений, так или иначе позволявших реализовать обмен данными между приложениями (среди получивших наибольшее развитие - Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) и Common Object Request Broker Architecture (CORBA)), однако каждая из них была довольно сложна в реализации, не обладала необходимой универсальностью (т. е. все же зависела от выбора, например, одной и той же операционной системы для всех участников обмена) и, что особенно плохо, эти технологии с большим трудом стыковались между собой.
Веб-сервисы решают исходную задачу – задачу интеграции приложений различной природы и построения распределенных ИС.
К плюсам веб-сервисов можно отнести следующее.
Интеграция собственных бизнес-процессов с бизнес-процессами бизнес-партнеров и клиентов при меньшей стоимости нежели с использованием иных интеграционных технологий.
Веб-сервисы организуются в публичные реестры (UDDI-реестры, ebXML-реестры или иные), доступные заинтересованным лицам по всему миру, порог выхода компаний на новые рынки снижается, возможности наращивания клиентской базы напротив возрастают.
Веб-сервисы обеспечивают преемственность в отношении уже имеющихся ИС, т. е. они надстраиваются над существующими ИС, но не вместо них. Сохранность инвестиций в IT-инфраструктуру - нет необходимости в радикальных изменениях;
Построение новых корпоративных решений с применением веб-сервисов реализуется быстрее и совокупно дешевле, поскольку основное внимание сосредотачивается на создании бизнес-логики решения, программирование самих веб-сервисов лишь по необходимости “обрамляет” этот процесс, не требуя больших трудозатрат за счет эффективного применения повторно используемого кода и адаптированных средств разработки (IDE и SDK).
Не менее подробно остановимся и на минусах веб-сервисов:
Стандарты интеграции бизнес-процессов, вопросы управления транзакциями и выработка единых бизнес- и IT-политик взаимодействующих посредством веб-сервисов компаний находятся пока на стадии разработки (мы отметим следующие начинания: Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS (аббревиатура “BPEL” произносится кратко как “бипль”)) корпорации IBM, XLANG корпорации Microsoft и спецификации WS-Coordination и WS-Transaction – результат сотрудничества IBM, Microsoft и BEA). Очевидно, без их четкой формализации и опубликования построение ИС на основе веб-сервисов может идти лишь с переменным успехом;
Динамическое использование информации бизнес-реестров веб-сервисов, вызов веб-сервисов “на лету”, требует решения вопросов доверительности отношений между различными бизнес-реестрами.
Вопросы безопасности функционирования ИС на основе веб-сервисов пока не урегулированы до конца. Спецификация WS-Security – продукт деятельности корпораций IBM и Microsoft – в настоящее время достаточно молода, не “устоялась” и частично все еще дорабатывается. Однако, в силу общности положений спецификации WS-Security, уже готовится к выпуску следующий слой спецификаций, посвященных вопросам безопасности: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation.
Определения
Сервис (service) ресурс, реализующий бизнес-функцию, обладающий следующими свойствами:
является повторно используемым;
определяется одним или несколькими явными технологически-независимыми интерфейсами;
слабо связан с другими подобными ресурсами и может быть вызван посредством коммуникационных протоколов, обеспечивающих возможность взаимодействия ресурсов между собой.
Веб-сервис (см. “Web-services architecture requirements”) программная система, идентифицируемая строкой URI, чьи публичные интерфейсы и привязки определены и описаны посредством XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью Интернет-протоколов.
Сервисно-ориентированная архитектура (Service-Oriented Architecture, SOA) - компонентная модель, состоящая из отдельных функциональных модулей приложений, называемых сервисами, имеющих определенные согласно некоторым общим правилам интерфейсы и механизм взаимодействия между собой. SOA - не есть синоним веб-сервисов, а веб-сервисы - не есть единственный способ реализации SOA. SOA не является технологией или набором технологий, это - концепция, абстрактное представление реализации информационных систем с помощью сервисов безотносительно конкретных технологий.
XML - Extensible Markup Language - расширяемый язык разметки
SOAP - Simple Object Access Protocol - простой протокол доступа к объектам. Применяется для дистанционного вызова процедур по intranet и Internet, определяет формат запроса и параметров, переданных в запросе. Относится только к сообщению и не предъявляет никаких требований к реализации веб-служб или их потребителей.
WSDL - Web Services Description Language - язык описания веб-служб. XML ориентированный язык, который используется для описания возможностей веб-служб. Позволяет предоставить описание и расположение всех методов веб-службы, а также их параметры.
UDDI - Universal Description, Discovery and Integration - универсальное описание, обнаружение и интеграция. Открытый системный реестр, предназначенный для сохранения информации о веб-службе и ее публикации.
Сказки Java and Web-services
Опять же сам пока не разбирался - просто ищу материалы, чтобы попробовать что такое веб сервисы в Java разработке... Естественно все это планируется делать на OpenSource компонентах. Также дополнительно нужно овладеть базовыми навыками работы с Apache Derby, т.к. огромное количество примеров дается именно на этой СУБД.
Отличная базовая статья по написанию первого веб-сервиса с IBM DevloperWorks. Старенькая правда - конца 2004 года (Eclipse 3.1, Axis1.0), но уже тогда это было простое занятие!
Создание Web-клиента при помощи Eclipse Web Tools Platform
Быстрый старт OpenSource реализации web services engine от Apache
Axis2 Quick Start Guide
Вот еще свежая статья с WTP, а также другие рекомендованные статьи по работе с визардами
Using Web Service Explorer to test a Web service
Creating Bottom Up Web Service via Axis
Creating Top Down Web Service via Axis
Consuming Web service using Web Service Client via Axis
Дальше будет ... сам попробую вряд ли раньше выходных. Но думаю на новейшем дистрибутиве j2ee разработки должно быть еще проще. И работа с Derby также, т.к. Eclipse Europe JEE Development уже содержит в себе Data Tools Platform
Так сразу в тему смотрим демонстрацию Instaling and Using Eclipse IDE for Java Enterprise Developers. Демонстрация показывает где скачать, как установить, как создать веб-сервис, как его протестировать. Все это правда для JBoss, но тут действительно видно насколько это все просто!
В J2SE 6 добавлено API из J2EE javax.jws, javax.xml.ws и javax.xml.soap, а также расширенная поддержка аннотаций. Теперь можно делать так:
import javax.jws.WebService;
import javax.jws.WebMethod;
@WebService
public class HelloService {
@WebMethod
public String helloWorld() {
return "Hello, World";
}
}
Затем обрабатывать аннотации и получать код
package net.zukowski.revealed.jaxws;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;
@XmlRootElement(name = "helloWorldResponse", ➥
namespace = "http://revealed.zukowski.net/")
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "helloWorldResponse", namespace = "http://revealed.zukowski.net/")
public class HelloWorldResponse {
@XmlElement(name = "return", namespace = "")
private String _return;
/**
*
* @return
* returns String
*/
public String get_return() {
return this._return;
}
/**
*
* @param _return
* the value for the _return property
*/
public void set_return(String _return) {
this._return = _return;
}
}
и еще шикарный пример вызова сервиса поиска Google из приложения
import java.io.*;
import java.net.*;
import javax.xml.ws.*;
import javax.xml.namespace.*;
import javax.xml.soap.*;
public class GoogleSearch {
public static void main(String args[]) throws Exception {
URL url = new URL("http://api.google.com/GoogleSearch.wsdl");
QName serviceName = new QName("urn:GoogleSearch", "GoogleSearchService");
QName portName = new QName("urn:GoogleSearch", "GoogleSearchPort");
Service service = Service.create(url, serviceName);
Dispatch dispatch = service.createDispatch(portName,
SOAPMessage.class, Service.Mode.MESSAGE);
SOAPMessage request = MessageFactory.newInstance().createMessage(
null, new FileInputStream(args[0]));
SOAPMessage response = dispatch.invoke(request);
response.writeTo(System.out);
}
ЗЫ. Кстати появился первый порт VE для Eclipse Europe, работает если поставить его именно на JEE дистрибутив (из-за GEF и EMF)
-----------
Душ, кухня, уборная на колесах – это уникальный гибрид жилища и машины - автодом. Познакомиться поближе с производителями и моделями автодомов можно на Travelavto.ru.
Отличный отпугиватель собак "Superdogchaser" для защиты от агрессивных собак - ваше спасение от острых зубов бездомных животных.
Google Code Project
В общем задумался я над этим давно, но до сих пор тема до конца не оформилась в голове. Я недавно пытался начать этот разговор через ".Net или J2EE" разработку. Мысли путанные и не причесанные, но все равно просто интересно почему так получается.
Т.е. с одной стороны мы имеем платформу, например .Net и средства разработки типа VS, Delphi ... с видением таких систем поставщиком. Кроме самой платформы, средств для разработки на этой платформе, готовых закрытых фреймворков и подходов к разработке на конкретной платформе. Т.е. есть как бы один путь создания систем - пусть рекомендованный вендором. И большинство, особо не задумываясь, следует по этому пути. В принципе это не упрек - это хорошо, что подход есть, примеры есть, и также для многих компаний хорошо т.к. сохраняются инвестиции в обучение... Да и платформа хороша ...
С другой стороны есть OpenSource, например Java, где и возможных фреймворков гораздо больше (конечно же речь идет о J2EE). Но опять таки, проходя через непростой цикл выбора фреймворка, однажды выбрав его в качестве основы, большинство разработчиков на нем и остается (например сегодня не смотря на развитие JSF масса проектов продолжается, и начинаются новые на Struts). Опять же все перетекает в один метод, но только с большими усилиями по предварительному выбору?
И вот идем дальше - пример Eclipse, который стал не просто реальной альтернативой коммерческим IDE, но пошел еще дальше став полноценной платформой разработки, развертывания, обновления .. Т.е. по большому счету осталось два IDE - VS and Eclipse. И большинство компаний используют Eclipse в качестве базовой платформы.
А теперь теже веб-фреймворки. Про первенство Google вроде бы никто не спорит, так вот мне кажется, что если они и дальше будут двигать OpenSource разработку, и также оставаться лидерами web систем, не сойдут ли большинство фреймворков на нет и не будет ли большинство разработчиков делать веб-проекты на GWT + GoogleGears
ЗЫ. Извиняюсь за путанность. Сижу разбираюсь с Eclipse Data Tools Project
и предлагаю переводчику гугла свой вариант перевода
Динамическое обнаружение веб служб ...
Сбросили задачку на Delphi, потенциальная шабашка на 100$. Я бы и не связывался если бы не сама задачка.
В общем есть по определенному адресу сервис и есть у него WSDL. Сервис принимает файлы и некоторую дополнительную информацию. Файл этот и необходимая информация есть в пользовательской системе и необходимо по определенному действию пользователя вызвать метод веб сервиса ... т.е. вернуть WSDL, разобрать имена методов и их параметры, и как-то сформировать SOAP запрос для выполнения операции.
Если бы интерфейс сервиса был постоянный, то проблемы никакой нету - все решается довольно быстро и элегантно - по WSDL описанию строится интерфейс и просто вызываются его методы (даже code complete при этом работает, и есть обновления для всех версий делфи, начиная с 7 до последней версии 2007)
Но у меня описание по условию задачи может меняться, но программа при этом изменяться не должна ... В общем в поиске готовых демонстрационных примеров такой функциональности мне пока не повезло - прийдется видимо все-таки формировать SOAP сообщение вручную ..
** WSDL получается элементарно
X: THHTPRio;
...
X.WSDLLocation := WSDLUrl;
X.Service; //без этого что-то не работает ...
дальше просто используем
- X.WSDLItems.GetServices()
- X.WSDLItems.GetMessages()
- X.WSDLItems.GetParts()
- X.WSDLItems.GetPartNode()
** а вот с формированием ответа нужно читать структуру SOAP запроса ..
********
Сегодня на рынке широко представлены беговые дорожки и эллиптические тренажеры различных компаний. Заказав любой тренажер в интернет-магазине Telelux.ru, вы сможете воспользоваться услугой доставки.
Динамическое взаимодействие приложений
Вместо английского опять занимаюсь всем что под руку попадается... Решаем для одного потенциального клиента классический вопрос вопрос шекспира, или как его перефразировал Лесь Поддеревлянський "Як остоло купатися менi ... Чи може искупатись?"
Динамическое или статическое взаимодействие с чужими веб сервисами? Интерес мой тут пока плохо прослеживается, но все равно копаю тему - просто интересно. Далее я приведу поток сознания по этому поводу, а пока вспомнилась одна задача.
Как-то приходилось решать подобный вопрос, но с импортом прайс-листов и накладных. Любой нормальный разработчик хочет откреститься от написания мостов между приложениями, поэтому и возникают монстроподобные горы кода по поддержке взаимодействия между системами.
Задачу импорта решил на уровне данных, не слишком элегантно, но достаточно эффективно. Был написан код который через ODBC мог импортировать данные из других систем, нужно было ввести сиквел для выборки данных, и как расширение уточняющий сиквел. Например, нужен товар определенной точки. Пишется запрос товара и дополнительный запрос, который возвращает все точки, пользователь выбирает точку и код точки подставляется в запрос товара. Так я открестился от задачи взаимодействия между системами с целью выбора из них прайс-листов и накладных.
И вот теперь задача посложнее - нужно найти общее решение для взаимодействия на веб-сервисах. Но как это сделать, представляю пока смутно ... Размышления иллюстрируются для Delphi и уже сейчас видно одно из Delphi достоинств, хотя на глубокое понимание вопроса не претендую.
Итак "Delphi vs Other ..." по моему мнению, Delphi во многих вопросах страдает гигантоманией. Все складно получается, но только на самом высоком уровне, на котором уже очень трудно что-то отнять, но очень легко добавить. Java же наоборот, гигантоманией не страдает, но и решения получаются большими усилиями. Выручают фреймворки, и при этом остаются базовые средства и приемы и все это прекрасно со всех сторон задокументировано и обеспечено огромным количеством примеров.
===== Итак, немного мыслей про динамический SOAP. Самое интересное, не смотря на маленький личный интерес (я хочу срубить пару сотен и устранится, поэтому предлагаю самое простое и быстрое решение) этот вопрос должен серьезно интересовать клиента - так это его прямые затраты на разработку и поддержку целого слоя, к тому же приложение уже готово а значит и на некоторую адаптацию. Конечно нам предложили только вершину айсберга - пару сервисов, чтобы мы продемонстрировали возможный путь решения проблемы а все остальное он сделает своими силами. =====
Прежде чем говорить о динамическом связывании и динамических вызовах, хочется напомнить о простоте стандартного подхода Borland с импортом удаленных интерфейсов. Итак в простом случае вам нужно просто импортировать WSDL, при импорте создается файл pas с определением типов данных и интерфейсов удаленного взаимодействия. И мы программируем, как буд-то это наши родные (близкие) интерфейсы. Доступна проверка типов и все остальные радости.
Теперь как же можно строить динамическое взаимодействие. Первое это нужно построить модель такого взаимодействия, которая должна поддерживать как SWDL/SOAP, так и объекты приложения. И нужно не упускать из виду такой момент как возможные изменения самих удаленных интерфейсов и как это будет отражаться на изменении кода приложения.
Очевидно, что первым делом нам нужно вернуть удаленный интерфейс и получить список предоставляемых им функций. Это сделать довольно просто, тот же стандартный компонент THTTRIO прекрасно с этим справляется за 3-5 строчек кода. Код по выбору функции для вызова так же превратился в простую задачу.
Итак, у нас есть имя сообщения и список параметров, которые нужно передать для его выполнения. Но никакой связи между параметрами сообщения и объектами нашей программы у нас пока нету. И первый вопрос как построить такую связь и как она вообще должна выглядеть? Встает сразу дополнительный вопрос как реагировать на полученный результат отсылки сообщения
*** Выбирается некоторое сообщение для отправки. И начинается процесс формирования сообщения. Конкретное сообщение уже выбрано, но у него еще есть входные и выходные параметры!
Для входных параметров можно попробовать написать стандартный обработчик, опустив пока проблемы сложных и простых типов допустим это будет что-то такое
procedure OnBuildSOAPRequest(MsgName, ParamName, ParamType, var ParamValue)
Т.е. при формировании запроса, для каждого параметра сообщения нужно будет добавить код для его заполнения, например
if MsgName = 'SendOrder' then
begin
if ParamName = 'orderId' then ParamValue := tblOrder['ID']
else if ParamName = 'orderDate' then ParamValue := tblOrder['DATE_ORDER']
else if ParamName = // и в таком же духе дальше
end;
Как видно такой подход решает только часть вопроса. О какой динамике можно говорить, если для заполнения параметров нужно писать код ...
Хотя в каждом конкретном случае, возможны свои варианты. Так в варианте с таблицей, можно настроить таблицу отображения имен. Например для нашего заказа это могла быть такая таблица:
Soap Messages
messageId | messageName
10045589 | sendOrder
24334343 | approvalRequest
....
messageParamsMap
messageId | paramId | paramName | paramType | defaultValue
34343434 | 3434344 | orderId | integer
....
Соотвественно здесь нам нужно будет формировать эту таблицу, т.к. без нее ничего работать не будет, но если будет таблица то можно жестко закодировать ... конечно все это выглядит пока совсем упрощенно ...
OnSendSOAPRequest(MsgName, ParamName, ParamType, var ParamValue)
ParamValue := ParamMaps.Instance.GetValueFor();
Если мы нигде не сделали ошибок, формируя нашу таблицу, нам удалось послать запрос и мы возможно получили какой-то ответ, руководство к дальнейшим действиям нашего приложения, которы необходимо предпринять на ответное сообщение сервиса ... а если эксепшн, или просьба повторить сообщение из-за перегрузки сервиса в настоящий момент времени?
OnReceiveSOAPRequest(MsgName, ParamName, ParamType, var ParamValue)
Здесь правда опять можно пропарсить весь ответ и предоставить более комплексный вывод ...
Т.е. дальше вообще сплошные дебри начинаются. Во первых мы должны знать какие ответы мы можем ожидать. По идее это может быть описано в спецификации сервиса. В самом простом случае необходима поддержка двух моментов - успешное выполнение и исключение, и значит два возможных выхода из ситуации - т.е. обработка успешного сценария и обработка неуспешного ...
Если опять обратится к таблицам, то необходимо написать стандартные обработчик ответов сервера и таблицу с необходимыми функциями реакции на события
messageId | RegularMethod | ExceptionMethod
...
в общем чем дальше тем больше дебри нам светят и вывод остается таким, что дешевле строить закрепощенное решение с фиксированными интерфейсами. Кроме того, с самого начала разработки нужно пойти на определенный компромисс, чтобы существующий код поддерживал построение такой SOAP-адаптированной системы. Иначе если это не так, то существующий код нужно будет также менять.
Чек-лист для базы данных
Многоцелевые столбцы. Если столбец используется в нескольких целях, то велика вероятность, что существует дополнительный код, который служит для обеспечения использования исходных данных ‘‘по назначению’’, часто путем проверки значений в одном или нескольких других столбцах. В качестве примера можно привести столбец, в котором хранятся даты рождения клиентов и даты приема на работу сотрудников. Еще худшим последствием применения многоцелевого столбца является то, что он ограничивает возможности используемых функциональных средств; в частности, в рассматриваемом примере не учтено то, что когда либо может потребоваться хранить информацию о датах рождения сотрудников.
Многоцелевые таблицы. Аналогичным образом, если какаято таблица используется для хранения данных о сущностях нескольких разных типов, то ее появление в базе данных по всей вероятности является следствием упущения в проекте. В качестве примера можно назвать общую таблицу Customer, которая используется для хранения информации и о физических лицах, и о корпорациях. Недостатком подобного подхода является то, что для представления информации о физических лицах и корпорациях используются разные структуры данных, например, применительно к физическим лицам необходимо хранить сведения о фамилии, имени и отчестве, а для корпораций достаточно указать юридическое название. В подобной общей таблице Customer неизбежно появляются столбцы с NULLзначениями, относящимися к одним типам клиентов, но не к другим.
Избыточные данные. Наличие избыточных данных это серьезная проблема в повседневно эксплуатируемых базах данных, поскольку при хранении одних и тех же данных в нескольких местах возникает вероятность нарушения совместимости. Например, во многих организациях обнаруживается, что информация о клиентах хранится в нескольких разных местах. Изза этого многие компании фактически не имеют возможности составить точный список, позволяющий узнать, кто действительно является их клиентами. Проблема состоит в том, что, по данным одной таблицы, клиент John Smith проживает по адресу 123 Main Street, а в другой таблице указано, что он проживает по адресу 456 Elm Street. В подобных случаях фактически ситуация такова, что данные относятся к одному и тому же лицу, некогда проживавшему по адресу 123 Main Street, но сменившему свой адрес в прошлом году; к сожалению, John Smith не отправил в компанию столь ко заявлений об изменении своего адреса, сколько в ней имеется приложений, содержащих эти сведения.
Таблицы со слишком большим количеством столбцов. Если в таблице имеется много столбцов, это можно рассматривать как признак отсутствия слитности в структуре таблицы; повидимому, в этой таблице представлены данные, относящиеся к нескольким разным сущностям. Предположим, что в таблице Customer находятся столбцы, редназначенные для хранения трех разных адресов (адреса поставки, адреса выставления счетов и адреса, применяемого в течение сезона), или нескольких номеров телефонов (домашний телефон, рабочий телефон, сотовый телефон и т.д.). Повидимому, должна быть проведена нормализация этой структу ры путем добавления таблиц PhoneNumber и Address.
Таблицы со слишком большим количеством строк. Наличие крупных таблиц служит признаком проблем производительности. Например, при поиске в таблице с мил лионами строк нельзя обойтись без больших затрат времени. В связи с этим может потребоваться разбить таблицу по вертикали, переместив некоторые столбцы в другую таблицу, или разбить ее по горизонтали, переместив в другую таблицу некоторые строки. Обе эти стратегии способствуют сокращению размеров таблицы, что может привести к повышению производительности.
Многозначные столбцы. Многозначными называются столбцы, в которых в различных позициях представлено несколько разных фрагментов информации. Например, как многозначный рассматривается столбец с идентификатором клиента, в котором первые четыре цифры идентификатора клиента обозначают головное отделение компании этого клиента, поскольку для выявления дополнительной информации приходится выполнять синтаксический анализ значений из этого столбца (допустим, чтобы узнать идентификатор головного отделения). В качестве еще одного примера можно назвать текстовый столбец, используемый для хранения структур данных XML; очевидно, что структуры данных XML могут быть подвергнуты синтаксическому анализу для выявления представленных в них
фрагментов с данными. На практике часто обнаруживается необходимость реорганизации многозначных столбцов для разбиения содержащихся в них данных на отдельные поля с данными, чтобы можно было проще проводить обработку этих полей в виде отдельных элементов.
Наличие нереализованных изменений. Если изменения в схеме базы данных давно не проводились, по той причине, что могут возникнуть какиелибо нарушения в работе, например, пятидесяти приложений, которые получают к ней доступ, это может служить наглядным признаком того, что схему базы данных необходимо подвергнуть рефакторингу. Подобные опасения перед возможными нарушениями в работе явно свидетельствуют о неизменном возрастании риска полного отказа системы, а такая ситуация со временем только ухудшается.
Re: Рефакторин баз данных: эволюционное проектирование
Факт появления книги Рефакторинг баз данных: эволюционное проектирование конечно отметил. Но особого желания ее не то что покупать а даже смотреть не было. Вчера наткнулся на ссылку и решил немного копнуть глубже... В общем как я понимаю ничего особенно нового там быть не должно .. Evolutionary Database Design (ЕDBD)
Если же приходится сталкиваться с архитектурой базы данных с несколькими приложениями (рис. 2.7), то потенциально схема базы данных может быть связана с исходным кодом приложений, инфраструктурами доступа к базе данных и инструментами объектнореляционного отображения (ObjectRelational Mapping ORM), с другими базами данных (посредством репликации, извлечения/загрузки данных и т.д.), со схемами файлов данных, с тестовым кодом и даже с самой собой.
Я как-то сталкивался с подобными проблемами - база около 800 таблиц, с триггерами, процедурами, UDF. Ядро, на котором работают несколько внутренних приложений, и несколько коммерческих. Задача это конечно же не такая простая как в случае одного приложения и 30-50 таблиц. Не знаю помогла бы эта книга там или нет. Несмотря на объемы, отсутствие должного документирования - все работало и модернизировалось. И хотя время на это уходило много - наверное это общая проблема таких больших проектов и никакой книгой ее не разрешишь.
В общем я не читал этот труд, но нашел некоторые материалы и беру себе на заметку проблемы в проектировании БД. И кстати проблемы то общие - типа разделения на слои ответственные за свои участки работы. Правильный нормализующий дизайн с оставлением вьюх вместо проблемных объектов ... Когда то где-то смотрел хорошую статью, что-то типа" фен-шуй здоровье базы данных базы данных" но сейчас что-то не могу ее найти ..
Вот комментарий Марка Уайтхорна, кто он такой не знаю, выдвигает две основные причины появления плохо спроектированных БД.
Множество учетных БД созданы не профессиональными разработчиками а простыми бухгалтерами или другими работниками на местах. И эти разработки хороши с точки зрения функциональности, хоть и могут иметь плохой дизайн.
С другой стороны можно увидеть также БД разработанные профессионалами с использованием самых лучших в мире практик, которые провалились как следствие простого неполного понимания задачи.
З.Ы.
Если уж начал про БД - пропиарю AllFusion ERWin DataModeler 7.2 - скачал вчера Trial, и о чудо, он просто заработал с русским текстом без исправления русских шрифтов в реестре.
Огорчило, что инсталлятор потяжелел на 200 метров, видимо из за .Net 2.0 Runtime... Кто у нас ругался на 15 метров JRE 
А так версия порадовала небольшой переработкой интерфейса, историей и отменой операций ...
iBATIS in Action
Некоторое время назад опять встал вопрос про ORM. Один знакомый спросил пример CRUD приложения в JAVA и я ответил, что в JDBC все есть, но "настоящие Java разработчики" используют ORM и очень любят Hibernate. И Hibernate примеры найти гораздо легче чем JDBC. В общем человек загорелся, т.к. также как и я после Delphi долго не мог понять как же это делается в Java, чтобы одним махом подцепить DataSet к гриду ... заинтересовался iBATIS и вот читаю "iBATIS in Action". Сразу хочу отметить, что книжка неплохая, т.к. кроме практики самого iBATIS дает вводные в общие проблемы и их решения при разработке приложений работающих с БД.
И почему все-таки iBATIS а не Hibernate ... просто мне ближе и понятнее SQL, плюс в моих базах все еще много триггеров и хранимых процедур, простой клиент-сервер без проблем масштабирования.
Просто немного выдержек из книги ...
Bean vs Map
В общем iBATIS может возвращать как Bean так и Map. Я как-то выдвинул мысль, что ORM вам нужен только тогда, когда у вас есть сложная бизнес-логика, или вам нужно разгрузить сервер БД и перенести логику на средний слой (или если вы не знаете, что такое СУБД и хотели бы остаться в привычных сердцу и разуму ООП объектах).
Но самый главный залог успеха - это понять и определить интерфейсы через которые UI будет работать с данными Domain. И если это БД, то 90% приложения будет отображать коллекции данных в сетке и позволять выполнение вставки, редактирования, удаления - CRUD - т.е. основные функции:
- показать список (просмотр, установка фильтров, ...)
- показать запись (вставка, редактирование, удаление)
Для этого набора функций создание Bean будет в большинстве случаев просто лишней работой, которую тот же Hibernate может сделать за Вас.
Вот что по этому поводу говорит iBATIS in Action
Bean
====================
Performance
Strong typing at compile time
Compile-time name checking
Refactoring support in IDE
Less type casting
------------------------------
More code (get/set)
====================
Map
====================
Less code
------------------------------
Slower
No compile-time check
Weakly typed
More runtime errors
No refactoring
====================
As a general rule, using a bean is the recommended practice for domain data (i.e., getting an account or order out of the database for editing), whereas using a Map is recommended for less critical and more dynamic data (i.e., a report or other output methods).
...
попался кусок кода хорошего, который можно применить для коллекций бинов ...
public void listPropertyNames(Class c) throws IntrospectionException {
PropertyDescriptor[] pd;
pd = Introspector.getBeanInfo(c).getPropertyDescriptors();
for(int i=0; i< pd.length; i++) {
System.out.println(pd[i].getName()
+ " (" + pd[i].getPropertyType().getName() + ")");
}
}
Вынесение SQL за пределы приложения
Важная техника - т.е. все что изменяется нужно стараться выносить за пределы приложения, чтобы при этих изменениях не требовалась перекомпиляция приложения
Hibernate in Action
После "iBATIS in Action" подумал что будет нехорошо обойти стороной и "Hibernate in Action". Все таки название Hibernate появилось на моем горизонте несколько раньше чем iBATIS. И пусть этот труд и датирован 2005 годом, его все-таки стоит посмотреть... Как оказалось здесь есть немного по теории ORM
А вот и практически самое начало - ввод в проблему ...
"постоянство" это проблема котороя уже разрешена реляционной технологией и расширениями, такими как хранимые процедуры, или это более глубокая проблема, которая должна быть адресована специальной компонентной модели Java, такой как EJB? Должны мы вручную кодировать каждую примитивную CRUD операцию в SQL и JDBC, или эта работа должна быть автоматизирована? Как мы добьемся переносимости, если каждая СУБД имеет свой SQL диалект? Должны мы оставить SQL полностью и адаптироваться к новой технологии БД, такой как объектная БД? Дебаты продолжаются, но недавно решением было названо ORM и популярность его растет.
...
Приложение с моделью домена не работают напрямую с табличным представлением бизнес сущностей; приложения имею свою собственную объектно-ориентированную модель бизнес сущностей.
Вместо прямой работы со строками и столбцами результирующего набора SQL, бизнес логика взаимодействует с этой объектно-ориентированной моделью домена и ее рантайм реализацией как с графом взаимосвязанных объектов. Бизнес логика никогда не выполняется в БД (как хранимая процедура), она реализуется на Java. Это позволяет бизнес логике использовать естественные объектно-ориентированные концепции, такие как наследование и полиморфизм. В качестве примера, мы могли бы использовать хорошо известные паттерны проектирования, такие как Strategy, Mediator, and Composite [GOF 1995], каждая из которых зависит от полиморфного вызова методов. Теперь предостережение: не все Java приложения спроектированы таким образом, и они не должны. Простые приложения могли бы быть много лучше без модели домена. SQL и JDBC API вполне пригодны для действий с чистыми табличными данными, и новый JDBC RowSet (Sun JCP, JSR 114) делает CRUD (create, read, update, delete) очень легкими. Работая с табличным представлением данных прямо и хорошо понимаемое.
Однако в случае приложений с нетривиальной бизнес-логикой, модель домена помогает значительно улучшить повторное использование кода и его обслуживание.
Если мы снова взглянем на реляционные БД, мы в итоге наблюдаем несоответствие между двумя парадигмами.
SQL операции, такие как отображение и соединение всегда имеют результатом табличное представление. Это полностью отлично от графа взаимосвязанных объектов используемых для выполнения бизнес логики в Java приложениях. Это фундаментально различные модели, а не просто различные способы визуализации одной и той же модели.
...
далее идет несколько надуманный пример - пользователи и счета и проблема как реализовать адреса ... о том как хорошо иметь user-defined column types (UDT) и что не все СУБД его поддерживают ...
далее идет обсуждение проблемы подтипов ... проблема представления связей ... навигации по объектному графу ... и стоимости этих несоответствий
по наблюдениям авторов 30% кода java уходит на преодоление этих несоответствий ..
главная стоимость в области моделирования - обе модели работают с теми же самыми бизнес сущностями, но сильно отличаются...
потом плавный переход к архитектуре со слоем постоянного хранения, и мысли о ручном кодировании DAO классов в которое могут закрадываться человеческие ошибки и поэтому это нужно отдать ORM ... в общем вплотную подходит к вопросу....
ORM это автоатизированное постоянное хранение объектов Java приложений в таблицах реляционных БД, с использованием метаданных которые описывают соответствие между объектами и БД. Работает по трансформации данных их одного представления в другое...
ORM решение состоит из следующих элементов :
- API для выполнения базовых CRUD операций над объектами классов постоянного хранения
- язык или API для спецификации запросов которые ссылаются на классы и свойства классов
- возможности для спецификации метаданных соотвествия
- техника для ORM реализации взаимодействия с транзакциями для выполнения dirty checking, lazy association fetching, and other optimization functions
Mark Fussel [Fussel 1997], исследовал область ORM и определил следующие четыре уровня ORM качества
Pure relational
Чисто реляционная модель вокруг SQL операций. Хороший подход для простых приложений с низким количеством повторно используемого кода. Часто используются хранимые процедуры, убирая работу с бизнес уровня в БД
Light object mapping
Сущности представлены как классы, но вручную делается соответствие классов к таблицам. Довольно распространенных и успешный подход для приложений с малым количеством сущностей, или приложений основанных на метаданных моделей данных.
Medium object mapping
Приложения проектируются вокруг объектной модели. SQL генерируется во время построения системы с использованием инструментов генерации кода или в рантайм самим фреймворком. Запросы могут использвать ОО язык запросов. Объекты кэшируются слоем постоянного хранения. Хорошо работает для приложений среднего размера со сложными транзакциями, и где важна поддержка различных СУБД. Эти прложения не используют хранимых процедур.
Full object mapping
Поддерживает естественное объектное мделирование: composition, inheritance, polymorphisms, and “persistence by reachability.” Прозрачное хранение; persistent классы не наследуются от какого либо специального базового класса и не должны реализовывать специальных интерфейсов. Efficient fetching strategies (lazy and eager fetching) and caching strategies are implemented transparently to the application.
Эта книга (и естественно подразумевается именно Hibernate) как раз о последнем методе.
В итоге ORM это продуктивность, сопровождаемость, производительность, независимость от вендора
JDBC 4.0 кинули с DataSet
Начал делать процесс и первым делом уперся в интеграцию с другими системами - нету БД, нету работающих сервисов ...
Intalio|BPMS работает с БД, автоматически создает веб службы для выполнения SQL запросов и получения результатов, и разворачивает на сервере.
Скачал новую версию Apache Derby, и о чудо, заметил заявленное соответствие JDBC 4.0. Решил побаловаться с ожидаемыми BaseQuery, DataSet и остальным... А вот в финальном релизе спецификации их то и не оказалось (:
Хоть и с опаской относился к ORM, на деле для процессов они оказались полезными, т.к. напрямую из объектов можно генерировать WSDL и обмениваться уже объектами.
-----------------------------
Final Draft 01 November 06
-----------------------------
...
Removed the EoD chapter, targeting for JDBC.next removing the following:
remove the methods: Connection.createQueryObject, DataSource.createQueryObject, DatabaseMetaData.providesQueryObjectGenerator, CommonDatasource.getQueryObjectGenerator
remove the interfaces, enums and annotations: DataSet, BaseQuery, DataSetResolver, QueryObjectGenerator, ConflictingRow, DataSetSyncStatus, GeneratedKeys, AutogeneratedKeys, ResultColumn, Select, Update, SQLDataSetSyncException, SQLRuntimeException, QueryObjectFactory
**********
Узнать все про недорогие туры Новосибирска вам поможет портал nsk.vipgeo.ru.
Удобный функционал сайта и доступность более чем 10 000 наименований запчастей для грузовиков КАМАЗ сделало компанию АвтоЦентрСнаб лидером по поставкам запасных частей для большегрузных машин Камского автозавода. Купить запчасти КАМАЗ по низким ценам можно на сайте autosnabcentr.ru.