Дефрагментация мозга. Софтостроение изнутри
Шрифт:
<xsd: element name ="CurrentQuantity">
<xsd: complexType>
<xsd: all>
<xsd: element name ="quantity" type ="float"/>
</xsd: all>
</xsd: complexType>
</xsd: element>
</wsdl: types>
<wsdl: message name ="getCurrentInput">
<wsdl: part name ="body" element ="sqsxsd: CurrentQuantity"/>
</wsdl: message><wsdl: message name ="getCurrentOutput">
<wsdl: part name ="body" element ="sqsxsd: CurrentQuantity"/>
</wsdl: message>
<wsdl: portType name ="StockInventoryServicePortType">
<wsdl: operation name ="getCurrent">
<wsdl: input message ="sqs: getCurrentInput"/>
<wsdl: output message ="sqs: getCurrentOutput"/>
</wsdl: operation>
</wsdl: portType><wsdl: binding name ="StockInventoryServiceSoapBinding"
type ="sqs: StockInventoryServicePortType">
<soap: binding style ="document" transport ="http://schemas.xmlsoap.org/soap/http"/>
<wsdl: operation name ="getCurrent">
<soap: operation soapAction ="http://mycompany.com/getCurrent"/>
<wsdl: input>
<soap: body use ="literal"/>
</wsdl: input>
<wsdl: output>
<soap: body use ="literal"/>
</wsdl: output>
</wsdl: operation>
</wsdl: binding><wsdl: service name ="StockInventoryService">
<wsdl: port name ="StockInventoryServicePort"
binding ="sqs: StockInventoryServiceBinding">
<soap: address location ="http://mycompany.com/StockInventoryService"/>
</wsdl: port>
</wsdl: service>
</definitions>Третьим
В CORBA объекты функционируют на сервере, тогда как на клиенте находится только соответствующая заглушка ( stub ). То есть вы в программе вызываете какой-то метод, а на самом деле происходит обращение к серверу, вызов соответствующего метода у серверного объекта и возврат результата на клиента с возможным обновлением состояния локальных полей заглушки. Аналогично со свойствами объектного типа: связанный объект подгружается по мере необходимости. Всё это происходит прозрачно для программиста, которому не нужно вмешиваться в процесс взаимодействия, но желательно знать, что стоит за манипуляциями с заглушкой на клиенте. Соответственно, существует соблазн вместо реализации на сервере новой функции службы написать код непосредственно на клиенте, благо сделать это легко. Тогда, например, обработка достаточно большой коллекции объектов в цикле может вызвать интенсивный обмен сообщениями с сервером и возникновение узкого места в системе. Аналогичная проблема плохой реализации имеется и при работе приложения напрямую с СУБД.
В среде веб-сервисов вопрос с «нерадивым программистом» решили радикально – отменой самой возможности написать такой код. Несмотря на то что в 80 % случаев имевшаяся автоматическая загрузка была уместной и здорово сокращала программу.
Как уберечь кукурузу от насекомых-вредителей? Очень просто: выкосить её всю, к чертям. Вредители придут, а кушать нечего.
Возвращаемые веб-службами объекты не связаны с серверными за их отсутствием. Потому что у серверной части приложения нет состояния и, соответственно, не может быть никаких объектов в принципе. Обмен сообщениями происходит как и в обычной веб-среде: запрос – ответ без поддержки сессии. Общеупотребительная практика – использование DTO для передачи состояния объектов от клиента к серверу и обратно. Но DTO не содержит никаких ссылок на другие объекты, кроме вложенных. Его структура состоит из полей скалярных типов, разрешённых стандартом, вложенных объектов и массивов. Соответственно, вы не можете прозрачным образом динамически подгрузить недостающий объект, для чего придётся явным образом вызывать службу.Прозрачная загрузка объектов в клиентском CORBA-приложении
BookGroup group = catalog.getBookCategory("Программирование");
Book[] books = group.getItems; // один вызов сервера
foreach(Book book in books)
{
ShowInfo(book.Name +": ");
ShowInfo(book.getPopularity. getVotesCount); // два вызова
}Работа клиентского приложения с DTO в среде веб-служб
BookGroupServiceClient groupClient = new BookGroupServiceClient(url1);
BookGroupDTO group = groupClient.GetBookCategory("Программирование");
BookServiceClient bookClient = new BookServiceClient(url2);
BookDTO[] books = bookClient.GetByGroupId(group.Id);
foreach(BookDTO book in books)
{
PopularityServiceClient popularityClient = new PopularityServiceClient(url3);
PopularityDTO popularity = popularityClient.GetByBookId(book.Id);
int votesCount = popularityClient.GetVotesCount(popularity.Id);
ShowInfo(book.Name +": ");
ShowInfo(votesCount);
}Сила CORBA
Прогресс неотвратим
Войны не будет, но будет такая борьба за мир,
что камня на камне не останется!
Из анекдота времён холодной войны
Вы думаете, что большие ЭВМ вымерли или вымирают? Попытаюсь вас если не разубедить, то хотя бы проинформировать.
В 2011 году 93 % респондентов крупных компаний отметили, что интенсивность использования мейнфреймов в их деятельности увеличивается или, как минимум, стабильна, и они остаются критически важной платформой для ЦОДов и «облачных» систем. 62 % (в 2010-м таковых было 56 %) отмечают общий рост данного рынка, 47 % полагают, что его развитие хорошо стимулируется новыми задачами и новым программным обеспечением [86] .
Две трети опрошенных отводят мейнфреймам стратегическую роль, которая только увеличивается; 42 % отмечают особую важность мейнфреймов для облачных приложений, а 65 % даже намерены внедрять в управление этими машинами мобильный подход [87] .
Согласно данным IDC по региону EMEA, в классе решений high-end (системы ценой $250 тыс. и выше) мейнфреймы опережают другие платформы non-x86, имея по результатам 2011 года долю рынка 45 % в стоимостном выражении. При этом в данном регионе и в данном классе серверов средняя цена RISC-сервера – 580 тыс. долл., EPIC-сервера – 830 тыс. долл., мейнфрейма – 2,1 млн долл. Чем выше требования к производительности и защищенности системы (и цена, которую согласны платить за это заказчики), тем чаще выбор делается в пользу мейнфрейма… Если взять одну из наиболее мощных экономик Западной Европы – Германию, то там в 2011-м на рынке систем non-x86 класса high-end доля мейнфреймов в количестве поставленных систем составляла 33 %, а в денежном выражении – 66 %.
Такие цифры должны впечатлять, особенно на фоне демонтированных в 1990-х годах на драгметаллы советских ЭВМ. Безукоризненно проведённая операция по зачистке национального рынка с последующим его заполнением экспортной продукцией самого низкого ценового сегмента – серверами и ПК на базе x86.
Наиболее ходовым термином в софтостроении является «новые технологии». По умолчанию новые технологии олицетворяют прогресс. Но всегда ли это так? Даже если не всегда, то в условиях квазимонополий, поделивших рынки корпораций, отказаться от «новых» технологий рядовым разработчикам непросто, особенно работающим в сфере обслуживания под руководством менеджеров среднего звена с далёким от технического образованием, оперирующих понятиями освоения и расширения бюджета и массовости рынка специалистов, а не технологической эффективностью.
Произошла тихая революция. Ещё 15–20 лет назад сессии крупных поставщиков на конференциях разработчиков были своеобразным мастер-классом, где на бета-стадии испытывалась реакция аудитории на предлагаемые изменения. Сегодня повестка дня состоит в постановке перед фактом новой версии платформы, показе новых «фишек» и оглашении списка технологий, которые больше не будут развиваться, а то и поддерживаться. Действительно, солдаты от софтостроения не должны рассуждать. Они несут службу и должны молча овладевать оружием, закупкой которого занимаются генералы в непрозрачном договоре с поставщиками. Экономика потребления обязана крутиться, даже если в ней перемалываются миллиардные бюджеты бесполезных трат на модернизацию, переделку и переобучение.
NET
Цифры версий и релизов фреймворка. NET меняются со скоростью, заметно превышающей сроки отдачи от освоения и внедрения технологий. В качестве положительного момента отмечу тот факт, что можно перескочить со второй версии сразу на четвёртую, минуя третью и третью с половиной. Правда, уже анонсирована пятая.
Давайте подумаем, кто же выигрывает в этой гонке кроме самой корпорации, пользующейся своим квазимонопольным положением:
• Услуги по сертификации. Прямая выгода.