Conference pamsrc::objectbroker

    In addition to AIX, I'm also thinking of retiring SunOS.  While SunOS
    has been a popular platform in the past, there seems to be less and
    less urgency to keep it now that Sun Solaris has entered mainstream.
    
    Once again, can anyone identify a customer situation that may be
    impacted by the retirement of SunOS.  
    
    DG

    How will IIOP impact the multi platform situation in total, i.e. IBM
    MVS, AS400, HP-UX, etc.
    
    Having IIOP supported with the ObjectBroker (ASAP), then there is no
    real reason (at least no obvious one) to have other platforms natively
    supported with a Digital ObjectBroker unless today's sales figures vote
    for it. Thats also where standards are heading at.
    
    Lets say, IBM RS6000 AIX and SunOS could become first IIOP candidats
    which have to prove that IIOP works from OBB on Digital UNIX, OpenVMS,
    Windows 95 and WIndows NT.
    
    Forcing IIOP is what many of our customers are waiting for, not an
    ObjectBroker for AIX and SunOS. (Credit Swiss being an example) 
    
    The decision to have an ObjectBroker for AIX and SunOS was correct
    in the past given the known facts at that point in time. Since then,
    IIOP gains on importance. Also Java Applets will call Objects in the
    ORB (ObjectBroker) world using IIOP. This is where the market will head
    at.
    
    Sepp,

Current plans are to have IIOP on all the ObjectBroker server 
platforms. That means on all platforms except Windows16 which is a 
client only platform.

IIOP ORBs from different vendors can only exchange and share the
common features they implement. None of the vendor specific added value
can be used when exchanging between 2 different ORBs. This means that 
if you want to use a vendor specific enhancement, then you need to 
have that vendor's ORB everywhere. 

    We have more customers which do not like to support vendor specific
    features. They learned that doing so generates more costs, makes
    porting harder and makes dependent on vendor and products.
    
    We need OBB fully supporting IIOP to the latest agreed OMG standards,
    no more no less. And we need a branding that the standards we have
    agreed upon are fully achived to 100%. Therefore IIOP very important.
    With IIOP platform availability becomes less important. 
    
    .... reading evaluation documents from customers. It looks as if the
    robustness of ObjectBroker is a real + point over other ORB's.
    
    .... any further going product/vendor features are seriously
    investigated before they are allowed to be used. Customers evaluate
    features in terms of what it will cost when they have to exchange an
    ORB or port an application making use of vendor specific features for
    what ever reason. 
    
    .... and what they need or begin to build are COSS-like-services;
    (could be a market)
    
    Sepp,

Yes, more effort on IIOP and less on platform coverage.
Platform coverage is a good story but IIOP is better.

John D.

IIOP seems definitely the way to go, but I have the feeling we should 
wait to see it working before to take decisions that could have impact 
on current/potential customers. Here are a couple of questions:

- Will be performance increase/decrease using IIOP between two different 
  ORBs vs. two versions of the same ORB ? I was meeting a customer in 
  Sweden last week that has a lot of concerns with performance. He has 
  developped an application using about 50 CORBA objects 200 methods. 
  They have developped code generators (OLE, DBs, ...) taking performance 
  into consideration. For your information, they are really satisfied of
  OBB performance !

- Will the customer accept to have several management tools and dev. 
  tools ? The other Swedish customer is trying to reduce the development
  costs by (1) using OLE on desktop and (2) unify data access in 
  heterogeneous environments (relational DBs on WNT and VMS, DB2/IMS 
  DBs on MVS and DL1 DBs on VM/VSE, and CAD information on IBM AIX 
  (Katia from Dassault). With OBB we have a good message regarding the
  platform coverage, performance, management tools and OLE connection.

  IONA has strong message. For example, ORBIX has an offering for OLE 
  connection, ORBIX and DataBroker from I-Kinetics for unify data access.
  In addition IONA has established connection with tools vendors, for 
  example Nexpert (an expert system from Neuron Data) for real time 
  oriented production applications. 

In other words, be carefull with the marketing message and it could be
good to contact account managers of current/potential customers.

Frederic

    Frederic,
    
    Waiting for IIOp is probabbly not good. 
    
    But	Your absolut rigth concerning the unified development, absolut
    rigth! This IS the voice of a customer.
    
    However, there a not only customer, there is a market driven by
    different vendors and some of them are about to convince everyone to
    stand up for IIOP. 
    
    i.e. IIOP is the vehicle to make a JAVA Applet (in the JAVA Object
    System Space) talk to a OBB Object (in the ObjectBroker Object System
    Space). 
    
    If we enforce IIOP and make it perform, then we open our doors to many
    potential vendor which talsk IIOP from/to there object system space.
    
    Have an ORB for all platforms .... regarding unified developmet as a
    real issue (which needs to be sold to our customers) .... just say this
    twice .... also to ease after a while development, and have a CASE
    tools to provide as much code as possible for a wide set of target
    platforms is easier to achive if we maintain the current platform
    coverage.
    
    So what are other important platform (excotic platforms are out)
    
    We should try to see OBB as a channel opener ! 
    
    What we need is a stabel performing broker, adhering to standards,
    covering Mission Critical Large Environments (also IBM MVS), supporting
    a unified modell and code development on user friendly low cost
    development stations with late deployment to and problem-less build to
    IBM MVS Hosts.
    
    Frederic; regarding OLE Connectivity, (sich as enforced by IONA) just
    look this time at ObjectBroker_DTC Notes file, I just managed yesterday
    my first synthesizing of an Objectbroker bank object. it's just amazing
    what you see then on the PC, real good stuff, this DTC, even it's still
    in Beta.
    
    This DTC is a message we must shall give to customers, even if we have
    to go for another few months. DTC is real key to even more customer
    success.
    
    After all: It is a matter of how much we sell in the near future. If
    customers realy understand the competitive edge of our ORB against any
    other ORB, and if they realy start buying, then we have no need to stop
    to have a broker for every platform. This is a matter of resources,
    isn't it Dan ?
    
    Development is not made more easy with IIOP, the opposite is true. But
    who makes all the development himself. We are heading to a
    plug-and-play world. Large projects are also as often put in a
    situation that interoperability is the real main issue, not unified
    code availabilty.
    
    What ever we do, resources are limitting us.
    
    Sepp,

> IIOP seems definitely the way to go, but I have the feeling we should 
> wait to see it working before to take decisions that could have impact 
> on current/potential customers.

	Just to make clear, we will not be forcing customers to switch
	over to IIOP.  The product will support both (OBB and IIOP)
	applications and/or servers running on the same system.

    But what will you call it, if not forcing to use IIOP, if we drop (as
    Dan Gilfix is looking for) the availabilty on AIX and the SunOS 
    platform Versions. What alternatives has a prospect ?
    
    Sepp

> But what will you call it, if not forcing to use IIOP, if we drop (as
> Dan Gilfix is looking for) the availabilty on AIX and the SunOS 
> platform Versions. What alternatives has a prospect ?

	There appears to be some confusion here.  *If* either of both
	of the platforms mentioned in .0 are dropped as supported platforms,
	that would mean we would not be supporting OBB *and* IIOP protocols
	on those dropped platforms.

	IIOP support is not planned to be packaged as a seperate product.
	You will continue to install one product (RT or DEV kit) which
	gives you support for both OBB's proprietary protocol, and IIOP.

    By using IIOP on a OpenVMS or Windows NT System in conjunction with a
    ObbjectBroker I hope to be able to connect via IIOP to a lets say DSOM
    Broker from IBM or to a third party vendor providing a ORB on SUN OS or
    IBM AIX. What else do we use IIOP if not to have my Broker talk via
    some half way bridge to a other half way bride to a other ORB.
    
    AS far as I know is IIOP meant to make it not anyl longer a requirement
    to have a ORB from a vendor for all possible platforms but to make
    ORB's from different vendors talking to each other.
    
    <---- DEC ORB ----> DEC IIOP | Internet | IBM IIOP <---- IBM DSOM ---->
    
    This is what I know IIOP is for. 
    If this model is not rigth please correct me. 
    
    Perhaps IBM or any other vendor will not provide an IIOP Bridge (made
    up of a sender and a receiver) to talk to it's ORB; then I would
    understand if DEC provides this part as well.
    
    Sepp,

> what is IIOP used for if not for Interoperability of ORB's

	It's for as you said.  I'm still confused how you feel ObjectBroker
	will be forcing customers to use IIOP if we dropped AIX and/or SunOs??

> What else do we use IIOP if not to have my Broker talk via
> some half way bridge to a other half way bride to a other ORB.

	IIOP does not require any form of protocol bridge if both ORBs
	can natively talk IIOP.

> Perhaps IBM or any other vendor will not provide an IIOP Bridge (made
> up of a sender and a receiver) to talk to it's ORB; then I would
> understand if DEC provides this part as well.

	I'm not sure what you mean here.  Do note that it is not planned
	for this release (and I have no idea of the plans for future releases)
	to have ObjectBroker provide a OBB<=>IIOP bridge/gateway.  That means
	if even if both client & server sides are ObjectBroker's ORB, that
	both must be coded/compiled/linked as an OBB client & server, or
	coded/compiled/linked as an IIOP client & server.  Ie. an OBB client
	or server can only talk to an OBB ORB, just as it is today (not
	counting of course any inter-ORB bridges/gateways that already
	exist out there that support OBB, are there?).

	However an ObjectBroker IIOP client or server can talk to any
	other ORB's client or server that talks IIOP (either directly
	or via an IIOP<=>other-vendor's-protocol supplied by the
	vendor or 3rd party).

We currently have no plans to build full or half-bridges for the purpose
of providing IIOP.  That alternative was investigated and determined to
be insufficient to handle production environments.

As a result, the Bryce release of ObjectBroker is currently planned
to provide IIOP as a native protocol.



Paul Patrick

Because of our recent new business partnership, a decision on removing
platform support will have to be made with BEA. It is my guess that
these platforms will remain in ObjectBroker Bryce. 

    May my understanding of IIOP migth be wrong and so I beg you to help me
    up to speed.
    
    With IIOP, 
    
    I can (basically) connect OBB with DSOM (given DSOM supports IIOP)
    Yes:
    No:
    
    I can build a OBB Client and requests will either reach an OBB
    Implementation Server or a DSOM Implementation Server, ofcourse using
    the specific ORB development tools.
    Yes:
    No:
    
    I can build a DSOM Client and request will either reach a DSOM
    Implementation Server or an OBB Implementation Server.
    
    Yes: No. Having IIOP supported my 2 ORB's behave (nearyl) like 1 ORB as
    theire core's use IIOP (the inter orb protocoll) to talk to each other.
    
    Yes:
    No:
    
    Agents on OBB or DSOM are talking to each other (when dealing to find a
    implementation server) as they talk via the ORB core and then use IIOP
    to reach each other.
    
    Yes:
    No:
    
    Given this is all true, where is the need to have an OBB on AIX if
    AIX provides DSOM and IIOP as well as OBB provides IIOP
    
    It is the Aim of the Game to have less vendor specific ORBS using IIOP
    not more. It is the aim of the game that after all work an ORB could be
    implemented in each vendors OS abd talk to an other vendors ORB by
    means of IIOP. 
    
    Wethere any different ORB-pairs supporting inter ORB connections using
    IIOP or DCE-ESIOP achives production quality is a different criteria.
    
    
    What else then could the Internet Inter-ORB Protocol be used for if not
    for what I've said above?
    
    End of Msg.
    
    Sepp,
    

Re: .15

	I think I may of confused you refering to OBB and IIOP protocols
	in .12.  When I refered to an "OBB" client or server, I meant an
	ObjectBroker client or server generated/compiled/linked such that
	the protocol used to talk between client & server is ObjectBroker's
	proprietary protocol (some in the group have called this protocol
	OBB "classic").  Such a client or server built to use OBB "classic"
	can not talk to a peer using IIOP.

	If you want your ObjectBroker client or server to use IIOP you
	have to specifically request that via command options, and link
	against a different library.  That client or server will then
	be able to talk to any (see disclaimer below) client or server via
	IIOP only, which may or may not be ObjectBroker's ORB.  It will not
	be able to talk to to OBB "classic" clients and servers.

	Disclaimer: in theory an ObjectBroker client or server built to
	use IIOP can talk to any ORB that also supports IIOP.  However
	not all IIOP implementations may correctly (or parts of the the
	IIOP protocol spec may be interpreted differently by different
	vendors) implement IIOP possibly leading to problems.  Without
	testing, conformance testing, etc, I can not say ObjectBroker
	will interoperate against this DSOM product you mention.

ps: do keep in mind that for at least the first release to support IIOP
    that only C++ bindings are supported.  Also Windows 3.1 support is
    not planned.  So it's not expected that customers overnight switch
    over to IIOP.

    So that meas I as a customer have made a heavy investment in
    ObjectBroker Application Integration, using the "classic OBB" protocol.
    Now the game is over and I have to restart again because IIOP is now
    the common denominator and not the classic OBB protocoll. Beautiful,
    very nice, isn't it? I just have to exchange one Backbone by another
    one. Not very nice. Wheres the bennefit?
    
    It's definitly not what I want!
    
    I want as I described it. I want my Agent to try i.e. to connetc via
    classic OBB & TCP/IP first, then via classic OBB and DECnet and if that
    does not help via IIOP.
    
    Please have a look at the eseential distributed objects survival guide
    from Robert Orfali e all under chapter CORBA 2.0 ORB-to-ORB Bridging.
    In this figures /models one can see how ORB interoperate. 
    
    I ask you, when can I expect to get a bridge from the classic OBB
    Backbone to the new IIOP ORB Backbon (which will become the centeral
    intergalactic object buss sooner or later) unless everyone uses
    BEA-ObjectBroker.
    
    I think, we need both, a full blown Digital/BEA IIOP OBB, but we need
    as well more concentration on bridges to go from the "classic OBB" to
    any vendors IIOP based ORB.
    
    Sepp 

Today, ObjectBroker has no plans for a bridge between the current
ObjectBroker protocol and the ObjectBroker IIOP protocol. In the
future, if there is a business case that fits with BEA product
strategy to create a bridge then one may be done. That is not a
question that ObjectBroker engineering can possibly answer now. 

> Wheres the bennefit?

	The same benifit you get when you move from a propritary network
	backbone such as DECnet, to TCP/IP, except at a higher level.
	You'll no longer be locked into one vendor.

	Also note that IIOP is really GIOP over Internet (ie. TCP/IP)
	transport.  Which means DECnet transport is not an option if
	you use IIOP (though it wouldn't be hard to map GIOP onto
	DECnet [DIOP :-)], that's certainly not planned [kinda defeats
	the purpose]).

>     I want as I described it. I want my Agent to try i.e. to connetc via
>     classic OBB & TCP/IP first, then via classic OBB and DECnet and if that
>     does not help via IIOP.

	by "Agent" I believe you really mean your ObjectBroker "ORB"?

	It's not quite that simple (to try one stack and then the other)
	because of object reference differences and possibly IDL differences,
	among others.  Our design also doesn't allow a single process to use
	both the classic OBB C++ bindings and the IIOP C++ bindings (to of
	tried to combine the two would of at least doubled the schedule in
	my opinion).

> In this figures /models one can see how ORB interoperate. 

	It's easy to describe how a gateway/bridge work, it's another
	matter to implement for a specific ORB.  And the major factor
	as with any product is time & money (which includes human
	resources).  To do everything everyone wants, and all in
	a first release, would result in a product that never ships.
	Tradeoffs have to be made.  And it's always a given not
	everyone will agree with those tradeoffs.

>     I ask you, when can I expect to get a bridge from the classic OBB
>     Backbone to the new IIOP ORB Backbon (which will become the centeral
>     intergalactic object buss sooner or later) unless everyone uses
>     BEA-ObjectBroker.

	Sepp, you already know where to go for this type of question :-)
	Pick up the phone or email Dan Gilfax ....