Discussion:
Target x86/64/Windows xcompile ARM/Archlinux
(too old to reply)
Michael
2013-02-16 14:13:48 UTC
Permalink
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
2013-02-16 15:44:25 UTC
Permalink
Post by Michael
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
2013-02-17 16:41:40 UTC
Permalink
Post by 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.
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
2013-02-17 16:54:09 UTC
Permalink
Post by Thomas Richter
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 ;-)

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

Susanne Nolte in der iX
Johnny Willemsen
2013-02-18 13:39:47 UTC
Permalink
Hi,
Post by Volker Birk
Post by Thomas Richter
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

Wil Evers
2013-02-18 09:29:03 UTC
Permalink
Post by Thomas Richter
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
Loading...