Тенденции современного программирования. Плюсы vs Минусы

Ну да, про веб сервисы к примеру. Минусы я вроде перечислил.
1.Раздутие сетевого трафика, за счет передачи всё текстом, хотя на это многие уже положили с пробором.
2.Головняк с безопасностью, т.к. с файерволами не совсем понятно что делать.
3.Опять же требуется наличие IIS, вроде без него ничего работать не будет. А это лишний сервис и опять же потенциальная угроза безопасности. (если не прав, поправьте)

Что там за плюсы?

 

ED

Странно, а я думал что СОМ - платформонезависимый. Только опиши интерфейс и поддерживай его. Но XML конечно более универсален чем СОМ.
Так что вебсервисы могут пахать даже под юниксами? И средства разработки имеются?

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

 

все - в смысле когда их станет много.

 

о, тут чего-то интересное обсуждают, можно и я поучаствую.

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

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 нормально работали?

 

на компьютере клиента то, что может передавать и принимать XML и 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

Вы чем больше пишете, тем более складывается впечатление, что вы вообще не владеете предметной областью.
Учиться, учится и еще раз учится!!!

 

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.

Это не ко мне.

Чувствуется что вы много читаете, но очень мало применяете это в жизни.

 

а тенденции-то где? и куда современность подевалась?

 

Ну, вот, есть такое мнение уважаемого человека:

В одно сообщение все не поместилось. Продолжение ниже.

paraNoId добавил [date]1106923362[/date]:

Порезано и вырвано из контекста статьи мною. Уж извиняйте

Мысль ясна? :D Нет?
в двух словах, смысл в том, что утомленные чехардой и несовместимостями платформ/версий/etc., разработчики поползут в server-side сторону, оставив пользователям унифицированного html (читай - xml) клиента. На server-side разные технологии еще поборются (но победит, как всегда, Микрософт ). Это все касательно массового рынка ПО.

Что-то мне это напоминает... Дежавю?

 

А сколько еще этих фишек будет... В CS мире есть две крайние точки: "все на сервере" и "все на клиенте". Все технологии, как маятник, между ними мечутся.

не сказать, что совсем уж древняя. Семь месяцев.

 

ED,

Да.
только сначала еще раз перечитай предыдущие посты и ответь себе на следующие вопросы:
1) Действительно-ли твоя ссылка демонстрирует связку Apache -> JBoss, а не Apache -> Tomcat, запущеном под управлением JBoss?
2) Действительно-ли твоя ссылка служит наглядным примером, что такой коннект используется часто?

вовсе нет. хотя в моей жизни были интересные проекты связанные с web (один из которых -разработка фраймворка) все же они не были доминируюшими. Не люблю web. Он мне нужен был только для того чтобы пройти уровень Sun Certified Web Developer.

P.S. В одном из проектов работал вместе с волгоградцами, отзывы наилучшие. поэтому и заинтересовался этой темой в вашем лице. Но боюсь, что ошибся.
по последним сообщениям Вас ждет блестящая карьера программиста.

 

"... разработчики поползут в server-side сторону, оставив пользователям унифицированного html ..."
не поползут, так как "...веб-ориентированные приложения с их гадким, непоследовательным интерфейсом с большим временем реакции – большой шаг назад в отношении удобства и практичности (usability) интерфейсов ...".
и на самом деле больщинство пользоватлей "... волнует паршивый веб-интерфейс ..."

 

Конечно нет. Даже не смотря на то, что возможности Web интерфейса повышаются.
Но, веб-сервис не есть веб-браузер. Тем они и хороши, что представляют готовые (и логически законченые) бизнес сервисы (не раскрывая детали реализации), который может быть использован клиентами различного типа.

 

так, похоже, тенденций и не будет....

 

Уже поползли. И Вы, в том числе. В сторону веб-сервисов. Напомню, речь шла о переносе услилий разработчиков в серверную часть. Т.к. поддерживать клиентов под кучу платформ/версий слишком накладно. Плюс унификация доступа.

Конечно. Первое - серверная часть, 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. скорость - тоже в счет (программа работает медленнее).