Я не считаю, что иметь один веб-сервер для управления всеми выключателями в доме - хорошая идея. Всякая централизация прямо бьет по безопасности. В конце концов, сам Интернет был создан как сеть независимых компьютеров, децентрализованная в целях обороны! Зачем отождествлять Internet и WWW? Чтобы сделать некий ресурс доступным с минимумом затрат и максимумом эффективности, иногда лучше открыть к нему доступ на месте, а не перемещать в доступное место. Что дольше выживет - файл в сети P2P или страница на сайте, который в любой момент могут грохнуть хакеры или закрыть по бюрократическим причинам?

Ответ на »сообщение 21« (Александр Лозовюк)
___________________________

Известен, например, такой стандарт для текстового представления двоичных данных, как base64. Правда размер результирующего текстового файла возрастает по сравнению с исходным бинарным в среднем на 1/4-1/3. Этот стандарт и используется в спецификациях SOAP Messages with Attachments (http://www.w3.org/TR/SOAP-attachments) и Web Services Enhancements (WSE) 1.0 for Microsoft .NET (http://support.microsoft.com/default.aspx?scid=%2fservicedesks%2fwebcasts%2fen%2ftranscripts%2fwct071003.asp)

Ответ на »сообщение 19« (maloi_alex)
___________________________


>>>1. Как с помощью SOAP сервер может уведомть клиента о чем-либо, если у клиента на машине не запущен WEB-сервер ?

С HTTP - никак, т.к. ясно, что тот, кто принимает по http запросы есть сервер. SMTP - это скорее диковинка. В .Net Remoting, правда, можно пакеты и через дискету передавать :) Но говорить об Web-сервере для клиента, наверно, преувеличение. Для клиента хватит просто сокета, работающего в единственном выделенном для приема извещений потоке.

>>>2. А каже с безопасностью ?

С безопасностью не все плохо.  Во-первых, включаете в SOAP header идентификатор сессии, который возвращается клиенту от сервера после операции login (вызова soap-метода login). Вместо него можно использовать простую http cookie, если SOAP сервер заводит сессию. Клиент из MS SOAP библиотеки передает обратно все куки, которые пришли ему от сервера. Во-вторых, если вам нужна безопасность, обязательно используйте https.

>>>3. Не эффективней ли передавть бальшие объемы данных в упакованном двоичном формате, нежели в XML ?
Да, эффективнее, но, наверно, только по критерию минимума траффика. Придумайте сами, по какому критерию эффективнее нормальный XML. Но даже с точки зрения минимизации траффика существенный выигрыш вы можете получить уже только оптимизацией структуры XML. Стремитесь не передавать примитивные значения как содержимое xml-элементов, используйте атрибуты. Т.е. вместо

<any-element>
<primitive1>123</primitive1>
<primitive2>XYZ</primitive2>
</any-element>

используйте

<any-element primitive1="123" primitive2="XYZ"/>

Не эффективней ли передавть бальшие объемы данных в упакованном двоичном формате, нежели в XML ?


Для XML есть стандарт (не могу сейчас вспомнить точно название), который предполагает, что в текстовый документ могут быть включены двоичные данные. где-то была статья проде так и называлась  "XML и двоичные данные".

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

>>>
Как с помощью SOAP сервер может уведомть клиента о чем-либо, если у клиента на машине не запущен WEB-сервер ?
>>>

I do not think it is possible with Web Services over http. We often forget that Web Services can work via other transport protocols. On earlier stages of WebServices I used SMTP (email) transport. In this case, EVENTUALLY, client will learn about this SOAP message. You can call it even GUARANTIED DELIVERY AND TRANSACTION SUPPORT, Geez :-).
In Jini this is a common situation, where Activation framework kicks in.

>>>
А каже с безопасностью ?
>>>

Not very good. Though some complex PKI schemas are applicable. With all this Verisign manutia with digital certificates and signatures, looks ugly to me, however suppose to work. I kind of question myself in this case how to use UDDI in secure mode? The new serivce discovery is supposed to be sort of trusted mechanism... trusted for strangers? well, that stranger can get its own digital certificate from Verisign. So, in theory it should work, but in practice... I strongly doubt about it, to complex to be trusted... :-)

>>>
Не эффективней ли передавть бальшие объемы данных в упакованном двоичном формате, нежели в XML ?
>>>

It is already in spec. You can use MIME types to do just that. This is probably one of few things I like in Web Services :-)

cheers,

serge

Воросы:
1. Как с помощью SOAP сервер может уведомть клиента о чем-либо, если у клиента на машине не запущен WEB-сервер ?
2. А каже с безопасностью ?  >>>никак! :)) Какая безопасноcть на 80 порту, да еще и открытым текстом.... ?????????
? Не эффективней ли передавть бальшие объемы данных в упакованном двоичном формате, нежели в XML ?

"Service: - some paid action, usually restricted in time"
"Product: - a paid thing usually non restricted in time"

>>>
Так значит, Web-сервисы нужны для того, чтобы зарабатывать на предоставлении услуг, не важно каких(?).
>>>
I did not say Web Services are NEEDED, however they were DESIGNED to do just that. I think Web Services have some limited future, for small bussiness for instance (like eBay store owners :-)
However, having said that, I think also WebServices might be usefull in integration process of J2EE applications with "die hard" Microsoft followers with their "fifth column" (and last hope to survive a free product society) - .NET. But I strongly doubt about that.
>>>
Web-сервисы дают единый протокол обмена информации, не акцентируя внимания на конкретных приложениях. Тем самым позволяя перенести всю логику в Internet(WWW).
>>>

I agree in order to implement the idea of Web Services, the WWW is irrelevant.

>>>
А нужно ли переносить ВСЁ в Internet, ограничиваясь убогим протоколом http?
>>>

Yes, we need to put everything in some accessible for everybody media. Remember, -  "computer is the network". The media itself could be different however based on specifics of applications.
For example, I do not thing you wanna embed a WWW-server in every light switcher in your home (and communicate with it in nice XML format :-), but it is viable idea to have one (web server) for the whole house in order, for instance to control this light switcher as well as to do a whole lot of other things using other transport and system protocols.

Так значит, Web-сервисы нужны для того, чтобы зарабатывать на предоставлении услуг, не важно каких(?).
Другие технологии (CORBA, RMI, и др. P2P-комунникации) ориентированы на конкретное взаимодействие конкретных систем, без акцентирования внимания на протоколе.
Web-сервисы дают единый протокол обмена информации, не акцентируя внимания на конкретных приложениях. Тем самым позволяя перенести всю логику в Internet(WWW).
А нужно ли переносить ВСЁ в Internet, ограничиваясь убогим протоколом http?

>>>
Большинство стандартов для бытовой техники, конечно, не ориентированы на расточительный текстовый базис. Но там и речь о другом - некя архитектура для исполнения агентов, к примеру. Естественно, для этого soap совершенно не годится - со всех сторон.
>>>

Ok, good. Finally we have figured this out. Now, about .NET

>>>
А касательно маршалинга объектов через xml - о, это занимательная область. есть один рабочий и один разрабатываемый проект под .net, в которым всё взаимодействие происходит через xml. и это ещё слабо сказано. никаких проблем я не вижу здесь, если не требовать слишком много. иерархические данные представлять удобно.
>>>

Here is an old story: "Moisha is dreaming about the chicken, while inspector is eating it". I have just finished such project myself (a commercial one, so no cheating, real objects and real XML, not academic example). And I will tell you what... I do not see any future, at least right now for Web Services, too complex for corporations, a lot of invasion into corporate privacy and that means no way money will go that way. Yes, we can solve security problem with PKI and Digital Signatures of XML etc, etc.... but it is TOO COMPLEX.

What does it mean TOO COMPLEX? That means: 1) A big probability of backdoors. 2) Corporations do not like to have intermediators (middlemen) in their bussineses, since it contradicts to the golden principle "divide and rule", they used to conduct P2P biz relations and sign different contracts (price) for the same set services. 3) And finally,  - the killer. It cost MONEY to implement Web Services.

Is there any exit? I think it is. And this is free from the listed above drawbacks. I did it myself and completely satisfied with the result. I wrote a JCA HTTP adapter, using J2EE JCA architecture and CCI (common client interface). I have already wrote TCP/IP and working on proprietary TA/SNA/3270 ones.

Well, I promised to write about .NET
Yes, M$FT is strong, however .NET is playing "catch up" with J2EE, .NET is not even close to the level of maturity of the J2EE containers, needless to say about single platform availability. M$FT reminds me old IBM and there is a fundamental principle in the history of all previous imperies - finally they become ordinary (may be still strong) companies or countries. There is fundamental shift is going on in the industry. No more software "products", since software becomes free. So, software companies need to survive some how without selling software, right? Interesting, how? They start selling services and basically all of them become "customization shops". Look at recent purchase Price Water House by IBM for several billion dollars, why did they do that? Because Price Water House is a consulting (not a product) company with wide range of existing customers. 

I will be very surprised if MSFT will be able to repeat the Netscape story again.

cheers,

serge

Большинство стандартов для бытовой техники, конечно, не ориентированы на расточительный текстовый базис. Но там и речь о другом - некая архитектура для исполнения агентов, к примеру. Естественно, для этого soap совершенно не годится - со всех сторон.

А касательно маршалинга объектов через xml - о, это занимательная область. есть один рабочий и один разрабатываемый проект под .net, в которым всё взаимодействие происходит через xml. и это ещё слабо сказано. никаких проблем я не вижу здесь, если не требовать слишком много. иерархические данные представлять удобно.