1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.

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

Тема в разделе "Программирование", создана пользователем ED, 27.01.05.

  1. ED

    ED Участник

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

    Итак мы плавно перетекли сюда. (С) темы - Bob.
     
  2. Bob

    Bob Активный

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

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

    ED Участник

    128
    0

    вот. раздутие - не в счет.

    Ну как бы наоборот. Т.е. попробуйте DCOM пробросить куда нибудь за пределы своей сети. Вспотеть можно.

    Про IIS - это заблуждение. В той части. что если вебсервис - то .NET. Это не так. Т.е. .NET на стороне логики это конечно так, а вот если это не .NET, а j2ee или (сейчас скажу крамольные слова) win32 могут, и чаще всего живут не на IIS . Например популярный бесплатный JBOSS выдает сервисы c апача, BES со специальной версии апача, ну и т.д.

    Ну тот же XML. Он не моноплатформен, как COM. и универсален. Т.е. это мостик между платформами.

    Преобразование XML через XSLT вообще очень быстрое. в J2EE системах, а там в основном то XML гоняется в виде строк. преобразование (различное) занимает около 5% времени работы.

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

    ну к вебсервису можно сделать досту с люого клиента: вин32, дотнет. джава или unix какой нативный.
     
  4. Bob

    Bob Активный

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

    ED Участник

    128
    0
    С каких это пор? СОМ это только винда.


    Конечно. И средств разработки целый вагон.

    а доступ к сервису это кокретный URL . Что мещает его заблокировать? Ну и я бы насчет ВСЕ не говорил бы. Есть таки большие сомнения о повсеместном их внедрении.
     
  6. Bob

    Bob Активный

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

    AlTk Читатель

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

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

    1. раздутие - в счет (нужны более скоростные каналы).
    2. скорость - тоже в счет (программа работает медленнее).

    нативные вызова СОМ быстрее (всякие там RPC и LPC)

    ПС. я не против веб-сервисов и ХМЛ.
     
  8. Bob

    Bob Активный

    21.795
    2
    AlTk
    В гугле поискал, были. Например COMsource называется.
    Кстати, про мой 3й тезис хотел уточнить у ED. Необходим .Net для вебсервиса, можно обойтись без IIS. Что это такое .Net? Набор программ? Или com-объектов?
     
  9. AlTk

    AlTk Читатель

    10.692
    0
    Bob, цены глянул? ;)

    "это такое .Net? Набор программ? Или com-объектов? "
    попробую объяснить, как я понимаю (применительно к .Net):
    раньше были dll, потом сделали COM, появились proxy и stub (методы объекта напрямую не вызывались), потом сделали com+, появился ObjectContext (методы объекта опять напрямую не вызываются), теперь появился .Net и сборки - мало того, что методы объекта напрямую не вызваются, так еще отсутвует библиотека типов (*.tlb) - вся метаинформация находится в сборке. это позволило сделать не только наследование интерфейсов, как в COM, но и наследование реализации (как в ОО языке), только без необходимости перекомпиляции кода. так как методы напрямую не вызываются (мы имеем виртуальную среду выполнения), то никто не мешает сделать так, чтобв они вызывались через какого-нибудь посредника - в данном случае через посредника, понимающего XML и HTTP.

    веб-сервисы - это наиболее простая модель приложения, если нужно посложнее - надо использовать .NET Remoting, если же еще сложнее то Enterprise Services.
     
  10. Гость

    Гость Гость


    C Jboss работаю начиная с версии 2.4.х, дополз до 4.х, но смысл вашей фразы так и остался не понятным. Все это похоже на чепуху.

    Web-Service действительно удобный и, что не маловажно, легковесный способ коммуникаций. Кроме того, Web-service могут жить и вне платформы J2EE или .NET. Но как любой другой "сервис" web-service должен реализовывать бизнес-логику, которая, как правило, реализуется на одной из платформ.
     
  11. Bob

    Bob Активный

    21.795
    2
    AlTk то что ты написал, я более менее представляю, не в этом вопрос. Ты написал пояснение с точки зрения разработчика. Я имел ввиду что надо иметь на компе физически установленное, чтобы эти приложения написанные под .Net нормально работали?
     
  12. AlTk

    AlTk Читатель

    10.692
    0
    на компьютере клиента то, что может передавать и принимать XML и HTTP (в случае веб-сервисов).
     
  13. ED

    ED Участник

    128
    0


    Что такое jboss? Сервер приложений, который несет в себе логику в виде JavaBeans. как пример. Сам JBOSS не может отдать наружу результаты выполнения в виде вебсервиса, он может предоставить xml, который надо отдать. За транспорт http отвечает вебсервер, который умеет транслировать запросы на выполнение на Jboss, и отдавать результаты клиенту, соответсвующим образом. Чаще всего, зримо или незримо, за http отвечает апач. Это и имелось в виду.

    В чем я не прав?
     
  14. Гость

    Гость Гость


    Да ни в чем!

    JBoss действительно сервер приложений (тут ты угадал), который реализует набор сервисов J2EE, таких как EJB, JSP/Servlets, JMS, JAAS, JCA и т.д. Нет смысла перечислять их все. Сам JBoss реализован по архитектуре JMX. (это может пополнить вашу коллекцию терминов)

    JavaBeans не имеет к J2EE и серверам приложений никакого отношения. В J2EE определена спецификация Enterprise JavaBeans (EJB), которая не имеет ничего общего с JavaBeans определенными в J2SE, кроме слова JavaBeans:D Ни один специалист J2EE не позволит себе такой оговорки!


    No comments!
    :D

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

    ED Участник

    128
    0
    Гость
    Уважаемый, а то, что JBoss в качестве веб-контейнера использует апач, это ничего? Ой, извините, Apache Tomcat.
    Ой, и наверное sessionbean, кроме слова bean к ejb и j2ee тоже ничего общего не имеет?
    И то, что часто используется связка в виде апача (или iis), коннектора и jboss. Это тоже наверное мои выдумки.

    Ой я еще забыл, что настоящие программисты (уважающие себя), пишут слово Java исключительно с большой буквы, а ejb, только как EJB.
     
  16. Гость

    Гость Гость

    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. :)


    Это не ко мне.

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

    ED Участник

    128
    0


    А я утверждал обратное?



    Ссылок дать?


    Я не выкручиваюсь, я выпендриваюсь. :) Раз уж пошли разборки на уровне точек в названиях.
    Про j2ee - естественно, это же спецификация платформы, которая поддерживает компоненты EJB, сервлеты, JSP и прочая..


    Ну простите уж.

    Читаю я действительно много. Но применяю - тоже. Просто , судя по Вашим верхним высказываниям, Вы занимаетесь больше всякими веб штуками. а я - нет.
     
  18. AlTk

    AlTk Читатель

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

    paraNoId Участник

    236
    0

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


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

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


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

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

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

    ED Участник

    128
    0
    paraNoId
    У микрософта теперь новая фишка. Смарт-клиент. Где уже не все перекладывается на сервера.
    Эта статья не очень новая, т.е. первод - да, а сама статья - нет. Малость перврд запоздал.
     
  21. paraNoId

    paraNoId Участник

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

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

    ED Участник

    128
    0
    paraNoId
    Не знаю, сколько их будет. Я думаю, очень много :)
    Я долго слушал Ложечкина по этому поводу. Понял только одно, основная фишка это то (в статье о том же говорится), что когда пользователь работает в приложении он не должен знать, где все происходит, на сервере или у него на машине, т.е. если есть коннект на сервер, то он работает на сервере, если нет - то он продолжает работать локально. Т.е. подразумевается, что как минимум какая-то часть данных постоянно кешируется на клиенте, происходит реплика по возможности и т.д. Черти что, короче.
     
  23. Гость

    Гость Гость

    ED,


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



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

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

    AlTk Читатель

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

    Гость Гость


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

    ED Участник

    128
    0


    Я подготовлюсь, ладно? сейчас у меня нет времени на подробные ответы. К сожалению.

    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]:
    Какая то ерунда творится с форумом. Могу протолкнуть только маленькие сообщения
     
  27. AlTk

    AlTk Читатель

    10.692
    0
    так, похоже, тенденций и не будет.... :(
     
  28. paraNoId

    paraNoId Участник

    236
    0
    Уже поползли. И Вы, в том числе. :) В сторону веб-сервисов. Напомню, речь шла о переносе услилий разработчиков в серверную часть. Т.к. поддерживать клиентов под кучу платформ/версий слишком накладно. Плюс унификация доступа.
    Конечно. Первое - серверная часть, 2-е - один из клиентов, причем специфичный. Или это описка?
    Почему все зациклились на веб-браузере (и html)? Тем более в том виде, в каким они существуют сейчас. В исходной статье эта тенденция рассматривалась только в одном узком разрезе: на примере, когда клиентом выступает браузер, предоставляющий интерфейс для взаимодействия с человеком. Суть от этого не меняется.
    Во-во, я о том же. Кто-то ломится в открытую дверь. :)

    Кста, по поводу веб-браузеров. Осмелюсь дать прогноз, что в ближайшем будущем они будут предоставлять интерфейс, свободный от этих недостатков. На каких технологиях это будет сделано - другой вопрос. Надеюсь не будет таких IMHO уродливых проявлений, как у нынешних веб-сервисов (типа гоняние xml-документов http/smtp транспортом).
     
  29. Гость

    Гость Гость

    paraNoId

    браузер - есть программа, которая ИНТЕРПРЕТИРУЕТ html (и xml) документ для показа его человеку. Реализации интерпретации - разные у разных браузеров. Поэтому, пока, есть такой подход, и ничего лучше, чем xml, пока не придумали, а в ближайшее время и не придумают, мы будем иметь то, что имеем. Скорее все перелезет на xml, тем более, что html и xml не близнецы, но братья. Ведь в xml можно описать не все, но почти все. Да, это приведет к раздутию размеров, ну и что? уже сейчас, по большому счету, все равно, сколько документ весит, 10К или 100К.
     
  30. AlTk

    AlTk Читатель

    10.692
    0
    "... Напомню, речь шла о переносе услилий разработчиков в серверную часть. Т.к. поддерживать клиентов под кучу платформ/версий слишком накладно ..."
    а куда деваться?
    никуда усислия с клиента не денутся - те же веб-сервисы могут быть stateless, не поддерживать транзакции, кого-то может не удовлетворять стандартная безопасность/секретность и т.д.

    "... IMHO уродливых проявлений, как у нынешних веб-сервисов (типа гоняние xml-документов http/smtp транспортом).... "
    так вроде специально все для этого делалось, а иначе давайте вернемся к ну, например, сиквел серверному TDS. когда мы говорим о протоколах, отличных от перечисленных Вами, то тут уж точно без усилий на клиентской стороне не обойтись.

    "... сейчас, по большому счету, все равно, сколько документ весит, 10К или 100К.
    нет не все равно. я повторюсь:
    1. раздутие - в счет (нужны более скоростные каналы).
    2. скорость - тоже в счет (программа работает медленнее).