[omniORB] Support for omniORB

[Mark Shacklette]

Andy:  

I have some opinions on this.  I am a consultant in Chicago, and am currently
working for a LARGE insurance company (Billions in annual sales), and have
spent the past several months examining and benchmarking several different ORBS
on several different platforms, mainly Orbix, VisiBroker, and OmniORB on HPUX
10.20 and NT 4.0 and Linux.  My report will show that OmniORB on a Pentium 200
running Linux blows away the other competition, even when running on a $50,000
HP 9000/800 with a couple of processors and a half gig of memory.  OmniORB also
beats the competition on the HP itself.  Unfortunately, OmniORB would not be
considered (by the people I will turn my report in to) as a viable solution for
several reasons (I am not expressing any opinion as to the truth value of these
concerns):

1.	A fear that a research lab can be "closed" at the whim of anyone at
Oracle or Olivetti at any time.
2.	A fear that new research interests might leave development of OmniORB
in limbo at any time.
3.	Limited or no commercial technical support.

I do not believe my superiors at the insurance company would consider source
code availability as a commensurate trade for technical support or
dependability in terms of future development.  This of course is questionble,
but the reality of the matter is that IT chiefs are as worried about "looking
bad" with a corporate decision as anyone else, and, as they say, no one ever
got fired for buying IBM.  You can also sue them as a last resort. 
Nevertheless, I have still been able to include the Linux/OmniORB combination
in my research, and when the decision is finally made on which to choose
(VisiBroker or Orbix), they will nevertheless still have the results which show
OmniORB as dominant in their minds.

> 1. Which platform do you need to be supported?
>    Although omniORB has been ported to a number of platforms, we only
>    test and distribute binaries for a subset of these. We could expand
>    this subset in the context of providing commercial support.

I think certainly NT, Solaris, HP, AIX, and Linux, for a start.

> 
> 2. We would propose a mainly email support system.
>    Is this sufficient, or is there a requirement for telephone support?
> 

While many developers are going to comfortable with email support alone, I
believe you will struggle to get that large corporate customer without voice
support.  The nice thing is that they can afford it.  I'd offer two different
plans, email only (less $$$) and voice+email (more $$$).  You might also think
of setting up a support partnership with various consulting firms that could
provide cost-effective local on-site development support if the need existed. 
This is the sort of thing that is going to comfort the people I report to.

> 3. What are your requirements for response times for:
>    a) Advice and assistance with problems
>    b) Patches and release revisions for bug fixes
> 

Varies of course.  On average, I want a response within a day, and a solution
within two days.  If a bug needs to be fixed, obviously, more time will be
required.  Certainly, a bug fix within a week will impress me.  I think what is
more important is your attitude toward support.  I know that Iona's taken alot
of flak recently about their unresponsive and seemingly uncaring technical
support.

> 4. What additional core ORB features do you consider essential,
>    in order of importance? Note that the following features 
>    are currently missing.
> 
>    DSI/DII
>    IIOP over SSL
>    POA
>    IR
> 
Excellent question!  One of the additional things which will rule you out on
our project is your lack of an Interface Repository.  I researched using your
ORB with VisualEdge's ObjectBridge product which privides a COM/OLE<-->CORBA
translation.  It's a fast bridge and is used by numerous ORB vendors as the
basis for their own bridge (Visibroker is the latest to adopt them, Expersoft
already has their bridge out based on ObjectBridge).  ObjectBridge won't work
with OmniORB because you have no native IR.  The bridge needs the IR for its
browsing capabilities, as well as its runtime compilation.  I believe we were
croaking on a call to a get_interface method.  But that's from my memory.  So
an IR would be a helpful addition, because that would open the world of COM
interconnectivity.

If you're working on a non-web project, I believe you're needs for DSI/DII will
be less.  After the IR, I would put IIOP over SSL and then DSI/DII and finally
POA.  I imagine that those working on internet projects will need DII soon.  I
would certainly like to see Events and Transaction support in the future.

> 5. Which CORBA Services do you consider essential?

Naming
Events
Persistence
Transactions
Life Cycle (already???)

> 
> 6. How many developers would you require support for?
> 

About 10-15 on my current project.

> 7. Do you have any need for licences other than GPL & GLPL?
>  

I believe a choice of licenses and thus a choice of payment for those licenses
would be useful.  In all things, flexibility counts.
  
> Many thanks for taking an interest in omniORB.
> 

And thanks for such a damn fine effort.



Mark Shacklette
Partner
Integral Consulting
Three First National Plaza, Suite 1400
70 W. Madison
Chicago, IL 60602
312-214-6110