Java и все-все все через RPC

[Вий]

Интересен следующий аспект - какие механизмы RPC для коммуникации с внешним миром у Java в ходу?
Передаваться будут достаточно большие объёмы бинарных данных - посему, похоже, SOAP и XML-RPC не совсем эффективны? CORBA - древняя и тяжеловесная?

Общаться надо с аппликациями, написанными на C/C++

[minimax]

Интересен следующий аспект - какие механизмы RPC для коммуникации с внешним миром у Java в ходу?
Передаваться будут достаточно большие объёмы бинарных данных - посему, похоже, SOAP и XML-RPC не совсем эффективны? CORBA - древняя и тяжеловесная?

Общаться надо с аппликациями, написанными на C/C++

Я в свое время , ручками писал комуникацию через сокет - ниже некуда.
Бинарные данные на C/C++ сервере преобразовывал в XDR-формат, а для клиентов на Яве он и есть родной формат, так как все это RPC и XDR придумано было лет 30 назад именно фирмой Sun

[-borisffm-]

http://hessian.caucho.com/
Работает у нас с 2005 года. Была попытка SOAP(Axis) но не покатило (медленно и много XML:-))

borisffm

[-borisffm-]

Прочитал внимательно
Hessian для C++ мы не пользуем, так что тут не знаю, но он есть.
У нас Java - Java.

[Вий]

Прочитал внимательно
Hessian для C++ мы не пользуем, так что тут не знаю, но он есть.
У нас Java - Java.

Спасибо, посмотрим

[Гаврила]

сокеты
или файлы лить через какойнить шаред сторадж

[Вий]

Сокеты - это просто и понятно, но нужны вещи типа асинхронных событий и прочие радости, самому велосипед изобретать не хотелось бы.

[atar]

но нужны вещи типа асинхронных событий

JMS и прочая middleware? Вроде как вендоры, производившие в свое время CORBA, предлагают адаптеры для приложений на С. Да и бесплатного чего-то было. ActiveMQ, например.

и прочие радости

Для этого возможно потребуется использовать прочие продукты.

[Guest]

http://code.google.com/p/protobuf/

[Гаврила]

еще мимоходом наткнулся

BSON
Originally created by the team behind MongoDB, and still used in its storage engine,
the BSON (Binary JSON) specification can represent any JSON object in a binary form.
Interestingly, the main design goal was not space efficiency, but speed of conversion.
A lot of parsing time can be saved during loading and saving by storing integers and
doubles in their native binary representations rather than as text strings. There’s also
native support for types that have no equivalent in JSON, like blobs of raw binary
information and dates.

Thrift
With Thrift, you predefine both the structure of your data objects and the interfaces
you’ll be using to interact with them. The system then generates code to serialize and
deserialize the data and stub functions that implement the entry points to your interfaces.
It generates efficient code for a wide variety of languages, and under the hood
offers a lot of choices for the underlying data format without affecting the application
layer. It has proven to be a popular IDL (Interface Definition Language) for open source
infrastructure projects like Cassandra and HDFS. It can feel a bit overwhelming for
smaller teams working on lightweight projects, though. Much like statically-typed languages,
using a predefined IDL requires investing some time up front in return for strong
documentation, future bug prevention, and performance gains. That makes the choice
very dependent on the expected lifetime and number of developers on your project.

Avro
A newer competitor to Thrift, and also under the Apache umbrella, Avro offers similar
functionality but with very different design tradeoffs. You still define a schema for your
data and the interfaces you’ll use, but instead of being held separately within each
program, the schema is transmitted alongside the data. That makes it possible to write
code that can handle arbitrary data structures, rather than only the types that were
known when the program was created. This flexibility does come at the cost of space
and performance efficiency when encoding and decoding the information. Avro schemas
are defined using JSON, which can feel a bit clunky compared to more domainspecific
IDLs, though there is experimental support for a more user-friendly format
known as Avro IDL.

Protocol Buffers
An open sourced version of the system that Google uses internally on most of its
projects, the Protocol Buffers stack is an IDL similar to Thrift. One difference is that
Thrift includes network client and server code in its generated stubs, whereas protobuf
limits its scope to pure serialization and deserialization. The biggest differentiator
between the two projects is probably their developer base. Though the code is open
source, Google is the main contributor and driver for Protocol Buffers, whereas Thrift
is more of a classic crowd-sourced project. If your requirements skew towards stability
and strong documentation, Protocol Buffers is going to be attractive, whereas if you
need a more open, community-based approach, Thrift will be a lot more appealing.