Комментарии 27
Не нашел у вас в документации как же это примерно работает, как выглядит, что нужно для того, чтобы использовать платформу и самое главное, зачем это нужно?
«Платформа веб-сервисов с общим интерфейсом» — слишком уж абстарктное определение, имхо.
«Платформа веб-сервисов с общим интерфейсом» — слишком уж абстарктное определение, имхо.
Это вторая статья, но мы дали ссылку на первую статью где попытались изложить для чего это все нужно. Нет смысла дублировать содержание первой статьи в последующей.
На самом деле все очень просто, достаточно разобраться с одним сервисом, подключить (написать клиент к нему если его нет), поработать с ним и все. Работа с остальными сервисами будет такая же.
Можно провести параллели с Win API, которая дает набор функций, а разработчик уже сам решает как их использовать в своих приложениях. Но у нас набор функций формируется с уклоном разработки под web, со своими ньюансами, плюсами и минусами.
На самом деле все очень просто, достаточно разобраться с одним сервисом, подключить (написать клиент к нему если его нет), поработать с ним и все. Работа с остальными сервисами будет такая же.
Можно провести параллели с Win API, которая дает набор функций, а разработчик уже сам решает как их использовать в своих приложениях. Но у нас набор функций формируется с уклоном разработки под web, со своими ньюансами, плюсами и минусами.
НЛО прилетело и опубликовало эту надпись здесь
Логика приложения может находиться и на стороне сервера, все что нужно для обращения к методам это только возможность осуществления HTTP запросов и передача параметров.
С платформой можно сделать всю логику на своем сервере или всю логику на клиенте или комбинировать часть логики на сервере, часть на клиенте.
С платформой можно сделать всю логику на своем сервере или всю логику на клиенте или комбинировать часть логики на сервере, часть на клиенте.
НЛО прилетело и опубликовало эту надпись здесь
Вот прям серьезно пытаюсь понять и разобраться, но никак не получается.
> «С платформой можно сделать всю логику на своем сервере или всю логику на клиенте или комбинировать часть логики на сервере, часть на клиенте.»
Под платформой имеется в виду платформа Hivext, верно? Ну в таком случае, а без платформы нельзя всего этого сделать?
> «С платформой можно сделать всю логику на своем сервере или всю логику на клиенте или комбинировать часть логики на сервере, часть на клиенте.»
Под платформой имеется в виду платформа Hivext, верно? Ну в таком случае, а без платформы нельзя всего этого сделать?
Можно и без компиляторов писать программы в машинном коде, можно не использовать API операционных систем и начинать сразу с низкого уровня разработку приложения. Но зачем это делать, нужно двигаться вперед использовать инструменты высокого уровня. Это и есть развитие. Ну и разве это плохо когда дается еще один инструмент, мы стараемся сделать его качественным потому что любим свое дело.
Ну это то уж я понимаю. Прекрасно понимаю все предпосылки возникновения уровней абстракции. Разумеется, мне понятно, зачем API и почему изобрели веб-сервисы и DSL-языки.
Я хочу акцентировать вот на чем — не понятно, каким слоем абстракции является Hivext. Т.е. не вполне ясно, какое именно это развитие. Что мне мешает вместо Hivext писать веб-сервисы, допустим, на ASP.NET, который априори поддерживает все их фичи, использовать MVC-фреймворки для REST-сервисов, а в качестве клиента также использовать «все-что-мне-заблагорассудится» (в случае с JS, например, jQuery и любую хорошую UI-библиотеку к нему)?
Как видите, вопрос вполне резонный, ибо здесь нет ничего близкого к идее написания веб-проектов на машинном коде.
Я хочу акцентировать вот на чем — не понятно, каким слоем абстракции является Hivext. Т.е. не вполне ясно, какое именно это развитие. Что мне мешает вместо Hivext писать веб-сервисы, допустим, на ASP.NET, который априори поддерживает все их фичи, использовать MVC-фреймворки для REST-сервисов, а в качестве клиента также использовать «все-что-мне-заблагорассудится» (в случае с JS, например, jQuery и любую хорошую UI-библиотеку к нему)?
Как видите, вопрос вполне резонный, ибо здесь нет ничего близкого к идее написания веб-проектов на машинном коде.
так пишите, если у вас есть знания, время, деньги — повторяйте, переносите. А почему многие не пишут свои сервисы карт?
Хм… ну на самом деле когда были «лишние деньги», мы реализовывали как раз нечто аналогичное. А потом просто поняли, что по крайней мере на нашей платформе (.NET) все-все-все уровни абстракции веб-сервисов, кроме непосредственно прикладного (предметной области специфичного проекта) уже реализованы производителем технологии и остается только пользоваться. Там и WebServices, и WCF, и Data Services и все это на том уровне, на котором никакого энтузиазма просто не хватило бы сделать. При этом мы тоже были полны энтузиазма и делали свой велосипед.
Вот поэтому просто и хотелось бы узнать, действительно ли Hivext — это не просто еще один фреймворк-велосипед, а что-то новое.
P.S. Сервис карт — это конкретный прикладной сервис (набор сервисов), а не платформа или язык для сервиса. И логично, в соответствии с принципами SOA его юзать, чем писать свое.
Но сравнение для меня неверно, ибо, повторюсь, на примере .NET-платформы есть уже ВСЕ уровни абстракции, кроме непосредственной реализации конкретного сервиса.
Вот поэтому просто и хотелось бы узнать, действительно ли Hivext — это не просто еще один фреймворк-велосипед, а что-то новое.
P.S. Сервис карт — это конкретный прикладной сервис (набор сервисов), а не платформа или язык для сервиса. И логично, в соответствии с принципами SOA его юзать, чем писать свое.
Но сравнение для меня неверно, ибо, повторюсь, на примере .NET-платформы есть уже ВСЕ уровни абстракции, кроме непосредственной реализации конкретного сервиса.
И да, еще. Не пойму, где здесь повторение на примере ASP.NET WebServices. Все механизмы уже есть и для отдельных сервисов настройки пишутся в файлике настроек.
Помимо прочего, веб-сервисы не такая вещь, которая пишется за 5 минут по 100 штук в день, что настолько уж критично время их настройки и перенастройки.
Единственным аргументом вижу слово «знания» — но с другой же стороны — может тем, кто не понимает, что такое веб-сервисы, лучше их и не трогать?
Помимо прочего, веб-сервисы не такая вещь, которая пишется за 5 минут по 100 штук в день, что настолько уж критично время их настройки и перенастройки.
Единственным аргументом вижу слово «знания» — но с другой же стороны — может тем, кто не понимает, что такое веб-сервисы, лучше их и не трогать?
В своей работе вы все равно используете сторонние библиотеки, по сути это эклектика, проекты собираются из множества разных модулей. Очень редко когда создаются уникальные алгоритмы по обработке данных (в большинстве своем они все примитивны) все сводится управлению данными, созданию структур, чтению, записи. Есть структурные единицы и есть алгоритмы обработки данных, которые работают со структурированными данными. Цель платформы абстрагировать описание структурных единиц от языка программирования (или даже платформы) и абстрагироваться от языка на котором реализован алгоритм обработки данных. Для работы со структурными единицами делаем сервис структур. Для работы с алгоритмами обработки данных нужно реализовывать сервис исполнения кода на серверах (по сути облако).
Пойдем от простого к сложному сначала это будут базовые сервисы (сервисы которые используются в 90% веб-приложений), потом сервисы проектирования произвольных структур данных, и далее сервисы добавления своих алгоритмов обработки данных.
Пойдем от простого к сложному сначала это будут базовые сервисы (сервисы которые используются в 90% веб-приложений), потом сервисы проектирования произвольных структур данных, и далее сервисы добавления своих алгоритмов обработки данных.
да, можно сказать что веб-сервисы — это следующий уровень программирования. Т.е. ЯП развивались грубо говоря примерно так: Assembler -> C -> C#. Мы продолжаем цепочку Assembler -> C -> C# -> WebServices (Hivext). Веб сервисы придумали не мы, мы их просто реализовываем видя в них большой потенциал и будущее.
Только сейчас обратил внимание и на первую статью.
И, честно — не понял, какую нишу пытается занять продукт. Я не говорю, что что-то плохо или хорошо. Правда, просто не понял. Общее впечатление — фрэймворк, с готовыми типовыми «кусочками функциональности» для 90% веб-проектов.
В свое время мы пытались создать что-то похожее (точнее, похожее на то, как я это понял), пока не поняли, что это не нужно, по крайней мере для нашей платформы (мы использовали .NET, который сам по себе является таким фрэймворком).
Судя по здоровому энтузиазму создателей, у проекта Hivext есть определенное будущее, но вот хотелось бы понять какое именно оно может быть, кроме «Yet Another Web Framework».
И, честно — не понял, какую нишу пытается занять продукт. Я не говорю, что что-то плохо или хорошо. Правда, просто не понял. Общее впечатление — фрэймворк, с готовыми типовыми «кусочками функциональности» для 90% веб-проектов.
В свое время мы пытались создать что-то похожее (точнее, похожее на то, как я это понял), пока не поняли, что это не нужно, по крайней мере для нашей платформы (мы использовали .NET, который сам по себе является таким фрэймворком).
Судя по здоровому энтузиазму создателей, у проекта Hivext есть определенное будущее, но вот хотелось бы понять какое именно оно может быть, кроме «Yet Another Web Framework».
в последнее время я часто использую такие вещи как GoogleMap, GoogleVisualzation. Пусть Hivext и не сравнима с ними по функционалу, но зато легко привести пример чтобы стало понятнее что и зачем. Вы представляете как устроена ГИС (GoogleMap)? на бекенде стоит мощный сервер и наверно не один, на котором развернут сервер карт, который в свою очередь дергает БД с разными слоями, картами. все это довольно сложно устроенно. Вы работали когда-то с GooogleMap? Правда приятно и удобно работать? в тоже время вы не заботитесь о серверной стороне, о картах. Вот и Hivext забирает на себя сложность реализации и поддержки серверной части, в коплект которой входят транзакции, кеширование, прочее.
Не вполне понятно. Конечно, я как пользователь не забочусь о GoogleMaps-серверах. Мне вообще все равно как это работает. Главное — работает и я вижу карты. Но вот разработчику GoogleMaps'а так или иначе необходимо знать и понимать, как там все устроено.
В этом смысле, Hivext «забирает на себя сложность реализации и поддержки серверной части» у кого??? Если проект, который нужно построить на веб-сервисах, предполагает, что мне нужны сервисы с собственной специфичной логикой, тогда чем мне здесь поможет Hivext?
В этом смысле, Hivext «забирает на себя сложность реализации и поддержки серверной части» у кого??? Если проект, который нужно построить на веб-сервисах, предполагает, что мне нужны сервисы с собственной специфичной логикой, тогда чем мне здесь поможет Hivext?
вы близки к пониманию. правильно если вам нужны сервисы с собственной специфической логикой вы их сами и делате. Т.е. вы не паритесь про то что вам надо опять создавать логику входа/выхода, профайл, проверку данных, синхронизацию, прочее… т.е. то, что переходит и проекта в проект, зачем вам постоянно об этом заботится.
Если суть вашего проекта уникальный сервис, так вам надо максимально сконцентрироваться на разработке вашей изюминки. Hivext как раз поможет в этом. Если бы был такой сервис раньше, скорость разработки одного из моих проектов уменьшилась бы в 2-месяцев до 2-х недель. Потому как 70% времени было потрачено на стандартные операции с юзерами, хранением объектов, прочее. Это один из частных примеров.
Но опять же — даже уникальные ваши сервисы можно сделать на основе Hivext сервисов. Когда появится сервис структур вы сможете создавать любые обьекты, сущности, структры, типы. Давайте рассмотрим в чем заключается «цимус» уникальных сервисов: либо в специфических данных, либо в специфическом алгоритме обработки данных, либо в смеси первого и второго. Так вот данные можно хранить на основе Hivext сервисов. По сути вам надо будет только вставить свой уникальный алгоритм в сервисы.
И в заключение: теперь представьте что у вас есть доступ к вашим данным, сервисам по стандартизированному кросс-платформенному АПИ: .Net, Java, JavaScript, AIR, Flash, другое. Достучатся к сервисам можно из любого ЯП. Интерфейс АПИ максмально одинаковый. Ну думаю сами мысль закончите…
Если суть вашего проекта уникальный сервис, так вам надо максимально сконцентрироваться на разработке вашей изюминки. Hivext как раз поможет в этом. Если бы был такой сервис раньше, скорость разработки одного из моих проектов уменьшилась бы в 2-месяцев до 2-х недель. Потому как 70% времени было потрачено на стандартные операции с юзерами, хранением объектов, прочее. Это один из частных примеров.
Но опять же — даже уникальные ваши сервисы можно сделать на основе Hivext сервисов. Когда появится сервис структур вы сможете создавать любые обьекты, сущности, структры, типы. Давайте рассмотрим в чем заключается «цимус» уникальных сервисов: либо в специфических данных, либо в специфическом алгоритме обработки данных, либо в смеси первого и второго. Так вот данные можно хранить на основе Hivext сервисов. По сути вам надо будет только вставить свой уникальный алгоритм в сервисы.
И в заключение: теперь представьте что у вас есть доступ к вашим данным, сервисам по стандартизированному кросс-платформенному АПИ: .Net, Java, JavaScript, AIR, Flash, другое. Достучатся к сервисам можно из любого ЯП. Интерфейс АПИ максмально одинаковый. Ну думаю сами мысль закончите…
Ну такое АПИ для сервисов — это стандарты WSDL/SOAP и стиль REST. Все одинаково и независимо от платформы, безо всяких дополнительных фреймворков (REST — это вообще по сути чисто концептуальная абстракция вокруг HTTP, не более того).
То, что вы говорите «Потому как 70% времени было потрачено на стандартные операции с юзерами, хранением объектов, прочее. Это один из частных примеров.»
Здесь речь идет о фреймворке в распространенном его понимании — стремление унифицировать «логику приложения», чтобы дать возможность сосредоточиться на бизнес-логике. Этой же цели следуют MVC-фреймворки типа RoR.
По поводу кроссплатформенности — хоть убейте не понимаю, ибо сама концепция веб-сервисов как таковых построена на том, что к сервису обращаются «на языке веб-сервисов», а не на языке, на котором написан сервис. Грубо говоря, кросс-платформенность определяется уже самим понятием «веб-сервис».
Сервисы данных (если я правильно понимаю, что они из себя в Hivext-е представляют) уже давно существуют и как концепция, и как реализация. Те же Adobe LiveCycle Services, Microsoft ADO.NET «Astoria» Data Services и так далее…
Сами веб-сервисы, к примеру, на платформе .NET существуют в виде тех же ASP.NET WebService'ов. Т.е. берем, создаем проект типа «веб-сервис» и вуаля — вновь созданный файл содержит класс, который уже унаследован «откуда надо» и реализует всю функциональность именно веб-сервиса. Вся общая функциональность есть в самом .NET Framework. В мире Java есть аналогичные штуки.
То, что вы говорите «Потому как 70% времени было потрачено на стандартные операции с юзерами, хранением объектов, прочее. Это один из частных примеров.»
Здесь речь идет о фреймворке в распространенном его понимании — стремление унифицировать «логику приложения», чтобы дать возможность сосредоточиться на бизнес-логике. Этой же цели следуют MVC-фреймворки типа RoR.
По поводу кроссплатформенности — хоть убейте не понимаю, ибо сама концепция веб-сервисов как таковых построена на том, что к сервису обращаются «на языке веб-сервисов», а не на языке, на котором написан сервис. Грубо говоря, кросс-платформенность определяется уже самим понятием «веб-сервис».
Сервисы данных (если я правильно понимаю, что они из себя в Hivext-е представляют) уже давно существуют и как концепция, и как реализация. Те же Adobe LiveCycle Services, Microsoft ADO.NET «Astoria» Data Services и так далее…
Сами веб-сервисы, к примеру, на платформе .NET существуют в виде тех же ASP.NET WebService'ов. Т.е. берем, создаем проект типа «веб-сервис» и вуаля — вновь созданный файл содержит класс, который уже унаследован «откуда надо» и реализует всю функциональность именно веб-сервиса. Вся общая функциональность есть в самом .NET Framework. В мире Java есть аналогичные штуки.
По поводу кроссплатформенности — хоть убейте не понимаю, ибо сама концепция веб-сервисов как таковых построена на том, что к сервису обращаются «на языке веб-сервисов», а не на языке, на котором написан сервис.ок, но гораздо удобнее дергать методы объектов, методы прослойки, которая тупо поднимает объект из сервиса (в нашем случае это называется клиент). Зачем сделали DWR? все затем же, проще и удобнее дергатьметоды объектов
Сервисы данных (если я правильно понимаю, что они из себя в Hivext-е представляют) уже давно существуют и как концепция, и как реализация. Те же Adobe LiveCycle Services, Microsoft ADO.NET «Astoria» Data Services и так далее…Отлично, мы не говорим что мы уникальны в мире, наши конкуренты Microsoft, Google, Amazon.
У каждого есть своя изюминка. Кому-то нравится одно, кому-то другое. У вас сколько продуктовых магазинов в районе? наверно несколько, и в каждом есть посетители, верно?
Скажите, пожалуйста, а зарегистрироваться у вас сейчас нельзя для управления проектами?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Hivext: Платформа веб сервисов