Target x86/64/Windows xcompile ARM/Archlinux

[Michael]

Hello,

We are in a project and I am evaluating several ORBS for our app. Will
be an embedded hand-held device, for basic device services, and other
things like file transfers (probably), or other ORB exposed services.
Curious anyone else has had experience or would care to comment,
advise, etc.

As far as I know the latest omniorb is one of the ArchLinux/ARM CORBA
ORBs available: well, looks like THE one for C++ anyway, which is what
we need. Plus it seems with some nice Python-y features for session
capture, playback, and so on. Might be nice to advertise that sort of
potential as well, but for now focused on the CORBA tech itself.

Obviously, our app must be asynchronous in nature to/from servants.
There must also be asynchronous data callbacks into the app during the
experience. Probably in the form of rich (value types?) sequences
between app and servant, both command and callback.

So seems as though, omniEvent (minimum) if not (also?)
omniNotification services are going to be necessary: tricky part with
that is, build for test in Windows environment, also how to cross
compile (if necessary) or just build and have ready on our ArchLinux
(TBD IMO)/ARM environment.

Being no stranger to distributed computing either, with COM, web
services and WCF experience, other ORBs I've (re-)visited on this
journey are: ACE+TAO(+CIAO) and MICO. I just downloaded omniORB and
are you kidding me?! It's TINY! That would help selling the "overhead"
of installing a CORBA framework.

Thank you.

Regards,

Michael

[Volker Birk]

Michael <mwpow...@gmail.com> wrote:
> I just downloaded omniORB and
> are you kidding me?! It's TINY! That would help selling the "overhead"
> of installing a CORBA framework.

I've good experiences with MICO and OmniORB, the former for C++, the
latter more used for Python environments.

But MICO is running as gateway, because we developed a protocol stack
for mobile networks which is solving problems like roaming and makes
messages small. This stack is implemented as CORBA intermediate, with
gateways. If there is something big like a Linux-Kernel running on the
mobile, it can be gatewayed to CORBA locally, too.

The application software sees plain CORBA – or, using one of the ready
made adapters, is seeing a web service, EJB, .NET Remoting or whatever
they need.

Yours,
VB.
--
“Wer also seinen Anwendern Übles will, sollte unbedingt die Einführung von
Windows 8 in Produktivumgebungen forcieren.”

Susanne Nolte in der iX

[Thomas Richter]

On 16.02.2013 15:13, Michael wrote:
> Hello,
>
> We are in a project and I am evaluating several ORBS for our app. Will
> be an embedded hand-held device, for basic device services, and other
> things like file transfers (probably), or other ORB exposed services.
> Curious anyone else has had experience or would care to comment,
> advise, etc.

Omniorb is definitely not a bad choice, made good experiences with it.
However, unless you need to address compatibility with legacy
applications, I would probably get rid of Corba in first place and
invest time into a technology that has a somewhat more active support
base - just think who is going to maintain old code based on corba in
ten years from now? It is basically a dying if not dead technology.

Greetings,
Thomas

[Volker Birk]

Thomas Richter <th...@math.tu-berlin.de> wrote:
> I would probably get rid of Corba in first place and
> invest time into a technology that has a somewhat more active support
> base - just think who is going to maintain old code based on corba in
> ten years from now? It is basically a dying if not dead technology.

I'm hearing that since some 20 years now. 20 years of active support,
BTW ;-)

[Wil Evers]

Thomas Richter wrote:

> However, unless you need to address compatibility with legacy
> applications, I would probably get rid of Corba in first place and
> invest time into a technology that has a somewhat more active support
> base

Which technology would you suggest?

- Wil

[Johnny Willemsen]

Hi,

> Thomas Richter <th...@math.tu-berlin.de> wrote:
>> I would probably get rid of Corba in first place and
>> invest time into a technology that has a somewhat more active support
>> base - just think who is going to maintain old code based on corba in
>> ten years from now? It is basically a dying if not dead technology.
>
> I'm hearing that since some 20 years now. 20 years of active support,
> BTW ;-)

Yes, and in that 20 years the specification and implementations have
kept moving forward. A big concern has been the very hard to use IDL to
C++ language mapping, but that has recently also been addressed by a new
IDL to C++11 language mapping.

Regards,

Johnny