Ноя
29
Рубрика: Новости. Автор: Посаженников Андрей, 29 Ноя 2009

как я хочу нормальный декбрь … холодный, свежий, беленький …

http://heeepi.livejournal.com/

Мой дядя самых чесных правил
когда не в шутку занемог,
он RSSчитать заставил
и лучше выдумать не мог.


Ноя
25
Рубрика: Новости. Автор: Посаженников Андрей, 25 Ноя 2009

Спасибо Сергею Орлику (Sergey Orlik) за наводку.

Появился манифест SOA, под которым стоят очень даже внушительные подписи, хотя сам манифест достаточно спорен.

SOA Manifesto

Service orientation is a paradigm that frames what you do. Service-oriented
architecture (SOA) is a type of architecture that results from applying service
orientation. We have been applying service orientation to help organizations
consistently deliver sustainable business value, with increased agility and
cost effectiveness, in line with changing business needs.
Through our work we have come to prioritize:

Business value over technical strategy
Strategic goals over project-specific benefits
Intrinsic interoperability over custom integration
Shared services over specific-purpose implementations
Flexibility over optimization
Evolutionary refinement over pursuit of initial perfection

That is, while we value the items on the right, we value the items on the left more.

Ali Arsanjani
Grady Booch
Toufic Boubez
Paul C. Brown
David Chappell
John deVadoss
Thomas Erl
Nicolai Josuttis
Dirk Krafzig
Mark Little
Brian Loesgen
Anne Thomas Manes
Joe McKendrick
Steve Ross-Talbot
Stefan Tilkov
Clemens Utschig-Utschig
Herbjörn Wilhelmsen

© 2009, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.

Guiding Principles

Например для меня странным показалось сочетание “Business value over technical strategy” и “Shared services over specific-purpose implementations”. С одной стороны, важнее технологических принципов должны быть бизнес-решения, с другой стороны, совместные сервисы важнее конкретных реализаций. Как правило, бизнес задачи требуют конкретного решения, а не создания совместного сервиса. Да и как “Evolutionary refinement over pursuit of initial perfection” соответствует “Business value over technical strategy” непонятно. В общем, непонятен мне этот документ, однако основопологающие принципы по ссылке внизу достаточно интересны и заслуживают на мой взгляд внимания.


SOA Manifesto Guiding Principles

We follow these principles:

Respect the social and power structure of
the organization.

Recognize that SOA ultimately demands
change on many levels.

The scope of SOA adoption can vary. Keep
efforts manageable and within meaningful
boundaries.

Products and standards alone will neither
give you SOA nor apply the service
orientation paradigm for you.

SOA can be realized through a variety of
technologies and standards.

Establish a uniform set of enterprise
standards and policies based on industry,
de facto, and community standards.

Pursue uniformity on the outside while
allowing diversity on the inside.

Identify services through collaboration with
business and technology stakeholders.

Maximize service usage by considering the
current and future scope of utilization.

Verify that services satisfy business
requirements and goals.

Evolve services and their organization in
response to real use.

Separate the different aspects of a system
that change at different rates.

Reduce implicit dependencies and publish
all external dependencies to increase
robustness and reduce the impact of change.

At every level of abstraction, organize each
service around a cohesive and manageable
unit of functionality.

Вот основопологающие принципы уже не противоречат друг другу (опять же ИМХО).

Все таки прискорбно будет, если хорошая идея SOA в ее исходном виде превратится в тему для “священных воин”.



http://heeepi.livejournal.com/

Объявление для повес: Подпишись на RSS!


Ноя
25
Рубрика: Новости. Автор: Посаженников Андрей, 25 Ноя 2009

Наконец то наткнутлся на сервис который облегчит мне общение с некоторыми особо упрямыми личностями. Наконец то есть куда послать холиварщиков, готовых рвать глотки ночь на пролет, споря что лучше. Так что всем на holywars.ru.

image



http://heeepi.livejournal.com/

Объявление для повес: Подпишись на RSS!


Ноя
25
Рубрика: Новости. Автор: Посаженников Андрей, 25 Ноя 2009

В своем прошлом блоге, я уже рассказывал как с использованием WCF и REST подхода создать произвольную ленту, выгрузить туда данные и настроить Federation Search для Windows 7 и Internet Explorer 8.
Однако отображение ленты может не понравится пользователям, которые обращаются к ленте новостей напрямую из браузеров, вроде Chrome, которые по умолчанию не умеют распознавать RSS фиды, да и представить при первой подгрузке фид хочется красиво. Поэтому стоит украсить ленту, чтобы сделать ее более приглядной. Как это можно сделать? Ведь по сути лента - обычная XMLка. Для этих случаем придуманы XSLT преобразования. Сейчас расскажу как сделать с его помощью фид для WCF красивее.
[cut]Итак, нам понадобится какай то XSLT шаблон для преобразования RSS фида в симпотичный HTML. Например, можно воспользоваться моим или модифицировать его подсвои нужды.

< < /span >xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"   xmlns:a10="http://www.w3.org/2005/Atom" > < < /span >xsl:output method="html"/ > < < /span >xsl:variable name="title" select="/rss/channel/title" / > < < /span >xsl:template match="/" >   < < /span >xsl:element name="html" >     < < /span >head >       < < /span >title >         < < /span >xsl:value-of select="$title" / >       < /< /span >title >       < < /span >link href="/rss.css" rel="stylesheet" type="text/css" media="all" / >     < /< /span >head >     < < /span >xsl:apply-templates select="rss/channel" / >   < /< /span >xsl:element > < /< /span >xsl:template > < < /span >xsl:template match="channel" >   < < /span >body >     < < /span >h1 >       < < /span >xsl:value-of select="$title" / >     < /< /span >h1 >     < < /span >xsl:apply-templates select="item" / >   < /< /span >body > < /< /span >xsl:template > < < /span >xsl:template match="item" >   < < /span >h3 >     < < /span >xsl:choose >       < < /span >xsl:when test="guid[@isPermaLink='true' or not(@isPermaLink)]" >         < < /span >a href="{normalize-space(guid)}" >           < < /span >xsl:value-of select="title" / >         < /< /span >a >       < /< /span >xsl:when >       < < /span >xsl:when test="link" >         < < /span >a href="{normalize-space(link)}" >           < < /span >xsl:value-of select="title" / >         < /< /span >a >       < /< /span >xsl:when >       < < /span >xsl:otherwise >         < < /span >xsl:value-of select="title" / >       < /< /span >xsl:otherwise >     < /< /span >xsl:choose >   < /< /span >h3 >   < < /span >h4 >     < < /span >xsl:value-of select="a10:updated" / >   < /< /span >h4 >   < < /span >xsl:value-of select="description" disable-output-escaping="yes" / >   < < /span >xsl:if test="count(child::enclosure)=1" >     < < /span >p class="mediaenclosure" >       изображение новости: < < /span >a href="{enclosure/@url}" >         < < /span >xsl:value-of select="child::enclosure/@url" / >       < /< /span >a >     < /< /span >p >   < /< /span >xsl:if > < /< /span >xsl:template >< /< /span >xsl:stylesheet >

Далее нужно привязать шаблон к xml. Делается это указанием шаблона слудующей инструкцией:

xml version="1.0" encoding="utf-8" ? >xml-stylesheet type="text/xml" href="/rss.xslt"? >< < /span >rss version="2.0" xmlns:a10="" >http" >://www.w3.org/2005/Atom" >

После этого, браузер (в моем случае - Chrome) начнет отображать информацию не в таком

image

а примерно в таком виде

image

Все вроде бы ничего, но осталась одна мелочь – прикрутить это все к WCF. Вот тут начинается магия. У меня просто так не получилось указать SyndicationFeed нужную мне xml’ку. Что в итоге у меня получилось:

Шаг 1. Функция генерации фида должна возвращать поток:

 _"s/{query}", BodyStyle:=WebMessageBodyStyle.Bare) > _Function Search(ByVal query As String) As IO.Stream

Шаг 2. Необходимо дописать нужную строку преобразования прямо в поток. После формирования FeedFormatter выполняем следующее:

Dim memstream As New IO.MemoryStreamDim writer As System.Xml.XmlWriter = System.Xml.XmlWriter.Create(memstream)writer.WriteProcessingInstruction("xml-stylesheet", "type=""text/xml"" href=""/rss.xslt""")writer.Flush()formatter.WriteTo(writer)writer.Flush()memstream.Seek(0, IO.SeekOrigin.Begin)System.ServiceModel.Web.WebOperationContext.Current.OutgoingResponse.ContentType = "text/xml"Return memstream

Форматер умеет писать в поток, поэтому можно записать все что сгенерировано в выходной поток, приписав к нему и инструкцию на подвязку xslt. При этом, поток необходимо перевести к нулевому индексу, чтобы при сериализации

Шаг 3. Наслаждаемся результатом.

image

Теперь в xslt шаблон нужно только добавить генерацию нужного html кода, подвязать стили и можно будет наслаждаться приличным видом странички.[/cut]


http://heeepi.livejournal.com/

Информация вразвес - Подпишись на RSS!


Авг
18
Рубрика: Идеи, Разработка. Автор: Посаженников Андрей, 18 Авг 2009

 

Этой статьей хочу начать ряд маленьких заметок по паттернам (шаблонам) проектирования, которые меня заинтересовали уже достаточно давно, но проанализировать их глубоко я так и не собрался. Ряд таких статей будет не только обзором паттерна, но также и анализом. Я попробую дать не только описание паттерна (тут думаю я буду опираться все же на обширную литературу), но и привести реальные примеры того, где они реально используются или могли бы быть применены. Итак, приступим.

Как сказал один мой умный коллега, вики – это очень хорошая отправная точка для того, чтобы обзорно познакомиться с предметной областью. Поэтому этот источник обойти ну никак нельзя.

Шаблоны проектирования (design pattern) — это многократно применяемая архитектурная конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного контекста и описывающая значимость этого решения.

Однако, шаблоны проектирования не являются сниппетами по своей сути. Их нельзя просто вставить в код. Да и применимы они могут быть не только к коду самому по себе, а ко всему что угодно. Если сравнивать с MS, то у них есть некой подобие паттернов – это Best Practices.

Классификация же у меня будет достаточно простой, такой чтобы было удобно потом писать маленькие статьи и ссылаться на них в этом посте. Получится некое подобие вики, но писать его буду только я (хоть какое то преимущество автора). Кроме того для того, чтобы подниматься по иерархии абстракций, я буду рассматривать сначала более низкоуровневые паттерны и перейду к более высокоуровневым, таким как паттерны интеграции корпоративных приложений.

0 Уровень – Алгоритмы, введение.

1 Уровень – Основные паттерны проектирования.

2 Уровень – Паттерны проектирования классов и объектов.

3 Уровень – Системные (архитектурные) паттерны.

4 Уровень – Паттерны интеграции корпоративных систем.

Так, получится 5 небольших по размеру статеек, которые прочитать будет не так уж и томно, а пользы они принесут достаточно (особенно мне).

Если с дерева ты слез, Подпишись на RSS!


Авг
14
Рубрика: Новости. Автор: Посаженников Андрей, 14 Авг 2009

По рекомендации коллеги делаю краткий обзор новинок, появившихся в WCF.NET 4.0 betta 1. Судя по тому, что версия всего лишь betta, ориентироваться на нее стоит лишь приблизительно, но уже сам список новинок интересен. Оригинал статьи можно посмотреть тут http://msdn.microsoft.com/en-us/library/ee354381.aspx.

Итак, что же может появиться в составе .NET Framework версии 4:

  • Упрощение конфигурирования. Появились параметры конфигурации по умолчанию, что делает конфигурирование проще и понятнее.
  • Поддержка протокола WS-Discovery.
  • Routing Service.
  • Улучшение поддержки REST.
  • Усиление интеграции WCF и WF.

Упрощение конфигурирования, параметры по умолчанию

Наверное, самое ожидаемое мною изменение. Практически вся настройка всевозможного вида каналов, биндингов, протоколов транспорта, настроек аутентификации, шифрования, сертификатов вынесено в конфигурацию. Конфиг превращается в кучу ссылающихся друг на друга разделов, которые достаточно непросто править вручную. Такой конфиг – ожидаемая плата за унифицированную модель программирования, которую предоставляет WCF. Теперь конфигурировать сервис должно быть проще.

Конфигурация Endpoint’ов

В версии 3.0, 3.5 если для ServiceHost не сконфигурированы Endpoint’ы, то генерировалось исключение. Теперь ServiceHost сам создаст Endpoint’ы, причем для каждого контракта, который реализует класс сервиса.

Конфигурация протоколов транспортного уровня

В Mashine.config теперь определяется маппинг дефолтовых протоколов. Теперь можно определить, какой binding будет использоваться для какого протокола по умолчанию. Выглядит этот раздел следующим образом:

<system.serviceModel>
<protocolMapping>
<add scheme= “http” binding= “basicHttpBinding” />
<add scheme= “net.tcp” binding= “netTcpBinding” />
<add scheme= “net.pipe” binding= “netNamedPipeBinding” />
<add scheme= “net.msmq” binding= “netMsmqBinding” />
</ProtocolMapping>

Такой же раздел можно засунуть и в конфигурацию сервиса, что облегчит жизнь, если нельзя менять конфигурацию машины.

Конфигурация Binding’ов

Каждый binding определяет параметры по умолчанию, которые используются, если вы явно их не переопределите в конфигурации или в коде. Раньше переопределение параметров для binding’а происходила только если привязать его к определенному endpoint’у. Теперь это делать необязательно. Можно не привязывать binding, параметры просто применятся как параметры по умолчанию для endpoint ‘ов, использующих binding нужного типа.

Конфигурация Behavior’ов

Также как и для binding’ов можно указывать неименованные behavior’ы. Например, можно по умолчанию включить WSDL описание через http:

<configuration>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior> <!– notice no name attribute –>
<serviceMetadata httpGetEnabled=“true”/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>

Стандартные Endpoint’ы

Появилась конфигурация для стандартных endpoint’ов. Например, появился стандартная конфигурация для MEX конфигурации с контрактом IMetadataExchange. Для нее установлен mexHttpBinding как binding по умолчанию. Данная конфигурация используется очень часто для предоставления WSDL описания сервиса. Теперь конфигурирование сводится к следующим строкам:

<endpoint kind=“mexEndpoint” address=“mex” />

Стандартные наборы конфигураций полезны, когда необходимо сконфигурировать стандартные endpoint’ы или немного отличающиеся от них (изменением одного, двух параметров).

Выводы по конфигурации

Упрощение конфигурации делает конфигурацию читабельней, процесс создания сервисов проще. Такое упрощение с одной стороны сглаживает для разработчика переход с asmx сервисов на WCF. Однако обратная сторона этого упрощения – необходимость знать и помнить в Runtime настроек сервиса по умолчанию, ориентироваться на них.

Упрощение ASP.NET/IIS хостинга

Используя новые возможности конфигурации по умолчанию становятся возможными такие простые и элегантные сценарии, как:

<!– HelloWorld.svc –>
<%@ ServiceHost Language=“C#” Debug=“true” Service=“HelloWorldService
CodeBehind=”
~/App_Code/HelloWorldService.cs” %>

[ServiceContract]
public class HelloWorldService
{
[OperationContract]
public string HelloWorld()
{
return “hello, world”;
}
}

Если заметите, и объявление сервиса, и объявление контракта сервиса происходит теперь в одном файле. Приведенное здесь объявление сервиса пожалуй самое минимальное что должно быть при создании сервиса.

При этом, при обращении к *.svc файлу WCF самостоятельно активирует ServiceHost, настроит для него endpoint по умолчанию. Если в Mashine.config также прописаны правила для предоставления описания сервиса по HTTP, оно также установится по умолчанию. На каждый контракт, который реализует сервис, создастся отдельный endpoint с параметрами по умолчанию.

Активация без файла

Если использовать для активации сервиса svc файлы, то endpoint будет иметь адресом привязки адрес svc файла. Таким образом, каждый endpoint, созданный по умолчанию будет иметь адрес svc файла плюс наименование контракта.

Однако имена svc файлов некрасиво смотрятся в URL, особенно если речь идет о REST сервисе. Используя IIS можно решить проблему, используя фильтрацию по URL адресам, однако, это вводит еще один уровень сложности для сервиса.  Поэтому для активации в WCF 4 можно использовать новую конфигурацию serviceActivations:

<configuration>
<system.serviceModel>
<serviceHostingEnvironment>
<serviceActivations>
<add relativeAddress=“/Greeting” service=“GreetingService”/>
</serviceActivations>
</serviceHostingEnvironment>
</system.serviceModel>
</configuration>

Активацию такого вида и назвали красиво “file-less activation”.

Discovery

Это нововведение в WCF – попытка реализовать WS-Discovery протокол для обнаружения сервиса. Протокол позволяет определять местонахождение endpoint’ов сервиса. Клиент просматривает endpoint’ы сервиса и определяет, какой из них соответствует его критериям. Клиент может выбрать endpoint и использовать его адрес для доступа к сервису.

Discovery может работать в двух режимах: управляемом и специальном. В специальном режиме, сервис может посылать широковещательное сообщение всем клиентам, которые к нему могут быть подключены о смене сети или уходе из сети. Такой режим является достаточно простым, но работает только в рамках локальной подсети.

В управляемом режиме необходимо с использованием Discovery proxy управлять endpoint’ами. Сервис взаимодействует с прокси напрямую, причем такое взаимодействие может быть реализовано и через границы подсети. Клиенты при этом взаимодействуют напрямую с прокси, выбирая наиболее подходящий им endpoint, Discovery proxy реализовать нескольк сложнее, чем специальный режим, однако он более гибок и снижает широкополосный трафик сети.

Чтобы включить специальный режим необходимо добавить следующую конфигурацию:

<configuration>
<system.serviceModel>
<services>
<service name=“CalculatorService”>
<endpoint binding=“wsHttpBinding” contract=“ICalculatorService” />
<!– add a standard UDP discovery endpoint–>
<endpoint name=“udpDiscovery” kind=“udpDiscoveryEndpoint”/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceDiscovery/> <!– enable service discovery behavior –>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>

После этого, можно будет обнаруживать сервис с клиента по UDP. Клиенты могут, используя Discovery обнаружить реальный адрес сервиса и использовать его для доступа. Для этого необходимо сконфигурировать клиента:

<configuration>
<system.serviceModel>
<client>
<endpoint
name=“calculatorEndpoint”
binding=“wsHttpBinding”
contract=“ICalculatorService”>
</endpoint>
<endpoint name=“udpDiscoveryEndpoint” kind=“udpDiscoveryEndpoint”/>
</client>
</system.serviceModel>
</configuration>

С помощью класса DiscoveryClient можно сначала обнаружить адрес сервиса, а потом подключиться и использовать его для выполнения операций.

// Create DiscoveryClient
DiscoveryClient discoveryClient
=
new DiscoveryClient( “udpDiscoveryEndpoint” );
// Find ICalculatorService endpoints in the specified scope
FindCriteria findCriteria
= new FindCriteria(typeof(ICalculatorService));
FindResponse findResponse
= discoveryClient.Find(findCriteria);
// Just pick the first discovered endpoint
EndpointAddress address
= findResponse.Endpoints[0].Address;
// Create the target service client
CalculatorServiceClient client
=
new CalculatorServiceClient( “calculatorEndpoint” );
// Connect to the discovered service endpoint
client.
Endpoint.Address = address;
Console.
WriteLine( “Invoking CalculatorService at {0}” , address);
// Call the Add service operation.
double result = client.Add(value1, value2);
Console.
WriteLine( “Add({0},{1}) = {2}” , 100, 200, result);

Данный сценарий достаточно прост, клиент просто сканирует сеть для обнаружения нужного ему контаркта. Ограничить поиск можно за счет введения областей для сервиса.

Для того, чтобы сообщить что у сервиса появилась новая точка привязки, или сервис стартовал, можно использовать Service Announcements.

С помощью раздела <serviceDiscovery> можно настроить endpoint’ы, которые будут использоваться сервисом. Для большинства случаем может подойти endpoint udpAnnouncementEndpoint. При этом, все также нужно настроить сервис для использования udpDiscoveryEndpoint.

<configuration>
<system.serviceModel>
<services>
<service name=“CalculatorService”>
<endpoint binding=“wsHttpBinding” contract=“ICalculatorService”/>
<endpoint kind=“udpDiscoveryEndpoint”/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceDiscovery>
<announcementEndpoints>
<endpoint kind=“udpAnnouncementEndpoint”/>
</announcementEndpoints>
</serviceDiscovery>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>

Для реализации событий перехода сервиса в состоянии online и offline реализован класс AnnouncementService. Клиент просто может создать экземпляр этого класса, начать слушать канал, после того, как сервис перейдет в то или иное состояние, он передаст широкополосное сообщение, которое вызовет событие на клиенте. Пример клиентского приложения может быть таким:

class Client
{
public static void Main()
{
// Create an AnnouncementService instance
AnnouncementService announcementService
= new AnnouncementService();
// Subscribe the announcement events
announcementService.
OnlineAnnouncementReceived += OnOnlineEvent;
announcementService.
OfflineAnnouncementReceived += OnOfflineEvent;
// Create ServiceHost for the AnnouncementService
using (ServiceHost announcementServiceHost =
new ServiceHost(announcementService))
{
// Listen for the announcements sent over UDP multicast
announcementServiceHost.
AddServiceEndpoint(
new UdpAnnouncementEndpoint());
announcementServiceHost.
Open();
Console.
WriteLine( “Listening for service announcements.” );
Console.
WriteLine();
Console.
WriteLine( “Press <ENTER> to terminate.” );
Console.
ReadLine();
}
}
static void OnOnlineEvent(object sender, AnnouncementEventArgs e)
{
Console.
WriteLine();
Console.
WriteLine( “Received an online announcement from {0}:” ,
e.
AnnouncementMessage.EndpointDiscoveryMetadata.Address);
PrintEndpointDiscoveryMetadata
(
e.
AnnouncementMessage.EndpointDiscoveryMetadata);
}
static void OnOfflineEvent(object sender, AnnouncementEventArgs e)
{
Console.
WriteLine();
Console.
WriteLine( “Received an offline announcement from {0}:” ,
e.
AnnouncementMessage.EndpointDiscoveryMetadata.Address);
PrintEndpointDiscoveryMetadata
(
e.
AnnouncementMessage.EndpointDiscoveryMetadata);
}

}

Управляемый режим является просто некоторым расширением специального. Discovery proxy при этом, является компонентом, который отслеживает статус endpoint’ов. Для реализации Discovery proxy предназначен класс DiscoveryProxyBase. Его наследники и есть реализация нужного proxy класса. Например:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,
ConcurrencyMode
= ConcurrencyMode.Multiple)]
public class DiscoveryProxy : DiscoveryProxyBase
Dictionary
<EndpointAddress, EndpointDiscoveryMetadata> onlineServices;
public DiscoveryProxy()
{
this .onlineServices =
new Dictionary<EndpointAddress, EndpointDiscoveryMetadata>();
}
void AddOnlineService(EndpointDiscoveryMetadata endpointDiscoveryMetadata)
{
lock ( this .onlineServices)
{
this .onlineServices[endpointDiscoveryMetadata.Address] =
endpointDiscoveryMetadata
;
PrintDiscoveryMetadata
(endpointDiscoveryMetadata, “Adding” );
}
}
void RemoveOnlineService(EndpointDiscoveryMetadata endpointDiscoveryMetadata)
{
if (endpointDiscoveryMetadata != null )
{
lock ( this .onlineServices)
{
this .onlineServices.Remove(endpointDiscoveryMetadata.Address);
PrintDiscoveryMetadata
(endpointDiscoveryMetadata, “Removing” );
}
}
}

Сервис тогда примет примерно такой вид:

class Program
{
public static void Main()
{
Uri probeEndpointAddress
= new Uri( “net.tcp://localhost:8001/Probe” );
Uri announcementEndpointAddress
=
new Uri( “net.tcp://localhost:9021/Announcement” );
ServiceHost proxyServiceHost
= new ServiceHost( new DiscoveryProxy());
DiscoveryEndpoint discoveryEndpoint
= new DiscoveryEndpoint(
new NetTcpBinding()new EndpointAddress(probeEndpointAddress));
discoveryEndpoint.
IsSystemEndpoint = false ;
AnnouncementEndpoint announcementEndpoint
= new AnnouncementEndpoint(
new NetTcpBinding()new EndpointAddress(announcementEndpointAddress));
proxyServiceHost.
AddServiceEndpoint(discoveryEndpoint);
proxyServiceHost.
AddServiceEndpoint(announcementEndpoint);
proxyServiceHost.
Open();
Console.
WriteLine( “Proxy Service started.” );
Console.
WriteLine();
Console.
WriteLine( “Press <ENTER> to terminate the service.” );
Console.
WriteLine();
Console.
ReadLine();
proxyServiceHost.
Close();
}
}


RSS читаю Я
Папа, Мама, Все семья!
Лишь Иван не подписался,
дурачком так и остался.


марта
29
Рубрика: Новости. Автор: Посаженников Андрей, 29 марта 2009

Скрипка издергалась, упрашивая,
и вдруг разревелась
так по-детски,
что барабан не выдержал:
“Хорошо, хорошо, хорошо!”
А сам устал,
не дослушал скрипкиной речи,
шмыгнул на горящий Кузнецкий
и ушел.
Оркестр чужо смотрел, как
выплакивалась скрипка
без слов,
без такта,
и только где-то
глупая тарелка
вылязгивала:
“Что это?”
“Как это?”
А когда геликон -
меднорожий,
потный,
крикнул:
“Дура,
плакса,
вытри!” -
я встал,
шатаясь, полез через ноты,
сгибающиеся под ужасом пюпитры,
зачем-то крикнул:
“Боже!”,
бросился на деревянную шею:
“Знаете что, скрипка?
Мы ужасно похожи:
я вот тоже
ору -
а доказать ничего не умею!”
Музыканты смеются:
“Влип как!
Пришел к деревянной невесте!
Голова!”
А мне - наплевать!
Я - хороший.
“Знаете что, скрипка?
Давайте -
будем жить вместе!
А?”
 
Владимир Маяковский. Лирика, 1914.

PS: Если посмотрите предыдущий пост - увидите что Евгения Венлиг поет именно это стихотворение.

Незнакомым с RSS-ом Просьба двигать тёмным лесом!


марта
19
Рубрика: Новости. Автор: Посаженников Андрей, 19 марта 2009

Нашел в дебрях youtube. Выкладываю потому что был в шоке и не могу просто напросто поступить иначе. Слушайте все, наслаждайтесь.


Это на мой взгляд самые трепетные песни исполненные Сургановой.
А вот еще два отрывка, исполненные уже Евгенией Венлиг.

Чтобы скинуть лишний вес, Подпишись на RSS!


марта
15
Рубрика: Новости. Автор: Посаженников Андрей, 15 марта 2009

Просто нашел очень милую на мой взглад фотку и решил выложить.

Забавная такая фота.

Будь как свежий огурец! Подпишись на RSS!


марта
11
Рубрика: Новости. Автор: Посаженников Андрей, 11 марта 2009

Уравнение 1

Человек = кушать + спать + работать + развлекаться
Обезьяна = кушать + спать
Следовательно:
Человек = Обезьяна + работать + развлекаться
Следовательно:
Человек - развлекаться = Обезьяна + работать
Вывод 1: человек который не развлекается подобен обезьяне, которая работает.
Читать полностью »

От сети не жди чудес - Подпишись на RSS!