Тенденции современного программирования, плюсы vs. минусы Итак мы плавно перетекли сюда. (С) темы - Bob.
Ну да, про веб сервисы к примеру. Минусы я вроде перечислил. 1.Раздутие сетевого трафика, за счет передачи всё текстом, хотя на это многие уже положили с пробором. 2.Головняк с безопасностью, т.к. с файерволами не совсем понятно что делать. 3.Опять же требуется наличие IIS, вроде без него ничего работать не будет. А это лишний сервис и опять же потенциальная угроза безопасности. (если не прав, поправьте) Что там за плюсы?
вот. раздутие - не в счет. Ну как бы наоборот. Т.е. попробуйте DCOM пробросить куда нибудь за пределы своей сети. Вспотеть можно. Про IIS - это заблуждение. В той части. что если вебсервис - то .NET. Это не так. Т.е. .NET на стороне логики это конечно так, а вот если это не .NET, а j2ee или (сейчас скажу крамольные слова) win32 могут, и чаще всего живут не на IIS . Например популярный бесплатный JBOSS выдает сервисы c апача, BES со специальной версии апача, ну и т.д. Ну тот же XML. Он не моноплатформен, как COM. и универсален. Т.е. это мостик между платформами. Преобразование XML через XSLT вообще очень быстрое. в J2EE системах, а там в основном то XML гоняется в виде строк. преобразование (различное) занимает около 5% времени работы. Ну и то, что доступ к вебсервису можно пробросить куда угодно - тоже плюс. ну к вебсервису можно сделать досту с люого клиента: вин32, дотнет. джава или unix какой нативный.
ED Странно, а я думал что СОМ - платформонезависимый. Только опиши интерфейс и поддерживай его. Но XML конечно более универсален чем СОМ. Так что вебсервисы могут пахать даже под юниксами? И средства разработки имеются? Ну это не главное. А вот как его наоборот заблокировать. При чем не все сервисы, а избирательно. Т.е. когда все перейдут на эти технологии возникнет желание блокировать, как сейчас блокируют определенные порты.
С каких это пор? СОМ это только винда. Конечно. И средств разработки целый вагон. а доступ к сервису это кокретный URL . Что мещает его заблокировать? Ну и я бы насчет ВСЕ не говорил бы. Есть таки большие сомнения о повсеместном их внедрении.
о, тут чего-то интересное обсуждают, можно и я поучаствую. "СОМ это только винда." на самом деле нет. сейчас не знаю, но были мосты между виндой и юнихом специально для СОМ, правда все это дело достаточно дорого стоило. 1. раздутие - в счет (нужны более скоростные каналы). 2. скорость - тоже в счет (программа работает медленнее). нативные вызова СОМ быстрее (всякие там RPC и LPC) ПС. я не против веб-сервисов и ХМЛ.
AlTk В гугле поискал, были. Например COMsource называется. Кстати, про мой 3й тезис хотел уточнить у ED. Необходим .Net для вебсервиса, можно обойтись без IIS. Что это такое .Net? Набор программ? Или com-объектов?
Bob, цены глянул? "это такое .Net? Набор программ? Или com-объектов? " попробую объяснить, как я понимаю (применительно к .Net): раньше были dll, потом сделали COM, появились proxy и stub (методы объекта напрямую не вызывались), потом сделали com+, появился ObjectContext (методы объекта опять напрямую не вызываются), теперь появился .Net и сборки - мало того, что методы объекта напрямую не вызваются, так еще отсутвует библиотека типов (*.tlb) - вся метаинформация находится в сборке. это позволило сделать не только наследование интерфейсов, как в COM, но и наследование реализации (как в ОО языке), только без необходимости перекомпиляции кода. так как методы напрямую не вызываются (мы имеем виртуальную среду выполнения), то никто не мешает сделать так, чтобв они вызывались через какого-нибудь посредника - в данном случае через посредника, понимающего XML и HTTP. веб-сервисы - это наиболее простая модель приложения, если нужно посложнее - надо использовать .NET Remoting, если же еще сложнее то Enterprise Services.
C Jboss работаю начиная с версии 2.4.х, дополз до 4.х, но смысл вашей фразы так и остался не понятным. Все это похоже на чепуху. Web-Service действительно удобный и, что не маловажно, легковесный способ коммуникаций. Кроме того, Web-service могут жить и вне платформы J2EE или .NET. Но как любой другой "сервис" web-service должен реализовывать бизнес-логику, которая, как правило, реализуется на одной из платформ.
AlTk то что ты написал, я более менее представляю, не в этом вопрос. Ты написал пояснение с точки зрения разработчика. Я имел ввиду что надо иметь на компе физически установленное, чтобы эти приложения написанные под .Net нормально работали?
Что такое jboss? Сервер приложений, который несет в себе логику в виде JavaBeans. как пример. Сам JBOSS не может отдать наружу результаты выполнения в виде вебсервиса, он может предоставить xml, который надо отдать. За транспорт http отвечает вебсервер, который умеет транслировать запросы на выполнение на Jboss, и отдавать результаты клиенту, соответсвующим образом. Чаще всего, зримо или незримо, за http отвечает апач. Это и имелось в виду. В чем я не прав?
Да ни в чем! JBoss действительно сервер приложений (тут ты угадал), который реализует набор сервисов J2EE, таких как EJB, JSP/Servlets, JMS, JAAS, JCA и т.д. Нет смысла перечислять их все. Сам JBoss реализован по архитектуре JMX. (это может пополнить вашу коллекцию терминов) JavaBeans не имеет к J2EE и серверам приложений никакого отношения. В J2EE определена спецификация Enterprise JavaBeans (EJB), которая не имеет ничего общего с JavaBeans определенными в J2SE, кроме слова JavaBeans:D Ни один специалист J2EE не позволит себе такой оговорки! No comments! :D Вы чем больше пишете, тем более складывается впечатление, что вы вообще не владеете предметной областью. Учиться, учится и еще раз учится!!!
Гость Уважаемый, а то, что JBoss в качестве веб-контейнера использует апач, это ничего? Ой, извините, Apache Tomcat. Ой, и наверное sessionbean, кроме слова bean к ejb и j2ee тоже ничего общего не имеет? И то, что часто используется связка в виде апача (или iis), коннектора и jboss. Это тоже наверное мои выдумки. Ой я еще забыл, что настоящие программисты (уважающие себя), пишут слово Java исключительно с большой буквы, а ejb, только как EJB.
ED, Web-container это не вебсервер. Это больше. С этого надо начинать. Для справки: JBoss в качестве web-контенера может использовать кроме Tomcat еще и Jetty. И тот и другой являются Mbean, что позволяют развертывать их под управлением сервера приложений. Никто не запрещает запустить и иной web-container. Да. да.да и еще раз да. Есть связка Apache (традиционный веб сервер, не путать с Apache Tomcat) -> AJP 1.3 Connector -> Apache Tomcat (или Jetty). JBoss тут не причем . В такой схеме Apache обрабатывает статический контент (html, картинки и т.д.) а сервлет контейнер - jsp/servlets. хотя эта схема используется очень редко, только в тех случаях, когда нужно развернуть много статического контента. В большинстве случаях Tomcat великолепно справляется с обработкой статического контента, поэтому-то эта схема и используется крайне редко. Выкручиваетесь? SessionBean имеет непосредственное отношение к Enterprise Java Beans в отличие от JavaBeans. будем смотреть спецификации? Кстати в расшифровке j2ee не нашел слово bean. Это не ко мне. Чувствуется что вы много читаете, но очень мало применяете это в жизни.
А я утверждал обратное? Ссылок дать? Я не выкручиваюсь, я выпендриваюсь. Раз уж пошли разборки на уровне точек в названиях. Про j2ee - естественно, это же спецификация платформы, которая поддерживает компоненты EJB, сервлеты, JSP и прочая.. Ну простите уж. Читаю я действительно много. Но применяю - тоже. Просто , судя по Вашим верхним высказываниям, Вы занимаетесь больше всякими веб штуками. а я - нет.
Ну, вот, есть такое мнение уважаемого человека: В одно сообщение все не поместилось. Продолжение ниже. paraNoId добавил [date]1106923362[/date]: Порезано и вырвано из контекста статьи мною. Уж извиняйте Мысль ясна? :D Нет? в двух словах, смысл в том, что утомленные чехардой и несовместимостями платформ/версий/etc., разработчики поползут в server-side сторону, оставив пользователям унифицированного html (читай - xml) клиента. На server-side разные технологии еще поборются (но победит, как всегда, Микрософт ). Это все касательно массового рынка ПО. Что-то мне это напоминает... Дежавю?
paraNoId У микрософта теперь новая фишка. Смарт-клиент. Где уже не все перекладывается на сервера. Эта статья не очень новая, т.е. первод - да, а сама статья - нет. Малость перврд запоздал.
А сколько еще этих фишек будет... В CS мире есть две крайние точки: "все на сервере" и "все на клиенте". Все технологии, как маятник, между ними мечутся. не сказать, что совсем уж древняя. Семь месяцев.
paraNoId Не знаю, сколько их будет. Я думаю, очень много Я долго слушал Ложечкина по этому поводу. Понял только одно, основная фишка это то (в статье о том же говорится), что когда пользователь работает в приложении он не должен знать, где все происходит, на сервере или у него на машине, т.е. если есть коннект на сервер, то он работает на сервере, если нет - то он продолжает работать локально. Т.е. подразумевается, что как минимум какая-то часть данных постоянно кешируется на клиенте, происходит реплика по возможности и т.д. Черти что, короче.
ED, Да. только сначала еще раз перечитай предыдущие посты и ответь себе на следующие вопросы: 1) Действительно-ли твоя ссылка демонстрирует связку Apache -> JBoss, а не Apache -> Tomcat, запущеном под управлением JBoss? 2) Действительно-ли твоя ссылка служит наглядным примером, что такой коннект используется часто? вовсе нет. хотя в моей жизни были интересные проекты связанные с web (один из которых -разработка фраймворка) все же они не были доминируюшими. Не люблю web. Он мне нужен был только для того чтобы пройти уровень Sun Certified Web Developer. P.S. В одном из проектов работал вместе с волгоградцами, отзывы наилучшие. поэтому и заинтересовался этой темой в вашем лице. Но боюсь, что ошибся. по последним сообщениям Вас ждет блестящая карьера программиста.
"... разработчики поползут в server-side сторону, оставив пользователям унифицированного html ..." не поползут, так как "...веб-ориентированные приложения с их гадким, непоследовательным интерфейсом с большим временем реакции – большой шаг назад в отношении удобства и практичности (usability) интерфейсов ...". и на самом деле больщинство пользоватлей "... волнует паршивый веб-интерфейс ..."
Конечно нет. Даже не смотря на то, что возможности Web интерфейса повышаются. Но, веб-сервис не есть веб-браузер. Тем они и хороши, что представляют готовые (и логически законченые) бизнес сервисы (не раскрывая детали реализации), который может быть использован клиентами различного типа.
Я подготовлюсь, ладно? сейчас у меня нет времени на подробные ответы. К сожалению. ED добавил [date]1106989297[/date]: Вот так вот. И мордой в грязь. Ну это полезно бывает иногда. ED добавил [date]1106989373[/date]: ED добавил [date]1106989403[/date]: Надеюсь, это не сарказм? Дело в том, что о карьере в будущем мне уже говорить поздно. Мне не 20 лет. ED добавил [date]1106989446[/date]: Уважаемый Гость, если Вас таки что-то заинтересовало, то, пожалуйста, напишите мне письмо, ED добавил [date]1106989483[/date]: с интересующими Вас вопросами, что бы уж если разочаровать, то навсегда, а если нет - то тоже. ED добавил [date]1106989504[/date]: Я честно отвечу на все Ваши вопросы. мой адрес e u g e n e ( a t ) d a n i l e n k o . v i s t c o m . r u ED добавил [date]1106989561[/date]: Какая то ерунда творится с форумом. Могу протолкнуть только маленькие сообщения
Уже поползли. И Вы, в том числе. В сторону веб-сервисов. Напомню, речь шла о переносе услилий разработчиков в серверную часть. Т.к. поддерживать клиентов под кучу платформ/версий слишком накладно. Плюс унификация доступа. Конечно. Первое - серверная часть, 2-е - один из клиентов, причем специфичный. Или это описка? Почему все зациклились на веб-браузере (и html)? Тем более в том виде, в каким они существуют сейчас. В исходной статье эта тенденция рассматривалась только в одном узком разрезе: на примере, когда клиентом выступает браузер, предоставляющий интерфейс для взаимодействия с человеком. Суть от этого не меняется. Во-во, я о том же. Кто-то ломится в открытую дверь. Кста, по поводу веб-браузеров. Осмелюсь дать прогноз, что в ближайшем будущем они будут предоставлять интерфейс, свободный от этих недостатков. На каких технологиях это будет сделано - другой вопрос. Надеюсь не будет таких IMHO уродливых проявлений, как у нынешних веб-сервисов (типа гоняние xml-документов http/smtp транспортом).
paraNoId браузер - есть программа, которая ИНТЕРПРЕТИРУЕТ html (и xml) документ для показа его человеку. Реализации интерпретации - разные у разных браузеров. Поэтому, пока, есть такой подход, и ничего лучше, чем xml, пока не придумали, а в ближайшее время и не придумают, мы будем иметь то, что имеем. Скорее все перелезет на xml, тем более, что html и xml не близнецы, но братья. Ведь в xml можно описать не все, но почти все. Да, это приведет к раздутию размеров, ну и что? уже сейчас, по большому счету, все равно, сколько документ весит, 10К или 100К.
"... Напомню, речь шла о переносе услилий разработчиков в серверную часть. Т.к. поддерживать клиентов под кучу платформ/версий слишком накладно ..." а куда деваться? никуда усислия с клиента не денутся - те же веб-сервисы могут быть stateless, не поддерживать транзакции, кого-то может не удовлетворять стандартная безопасность/секретность и т.д. "... IMHO уродливых проявлений, как у нынешних веб-сервисов (типа гоняние xml-документов http/smtp транспортом).... " так вроде специально все для этого делалось, а иначе давайте вернемся к ну, например, сиквел серверному TDS. когда мы говорим о протоколах, отличных от перечисленных Вами, то тут уж точно без усилий на клиентской стороне не обойтись. "... сейчас, по большому счету, все равно, сколько документ весит, 10К или 100К. нет не все равно. я повторюсь: 1. раздутие - в счет (нужны более скоростные каналы). 2. скорость - тоже в счет (программа работает медленнее).