Conference 7.286::digital

Ray,

    Not sure if you have already, but you may want to place this question in
   the OBJECTBROKER conference on SEND::OBJECTBROKER .


Rick

    DEC/EDI v2.x and above use ObjectBroker v2.5a (with some caveats here). 
    This allows us to implement a client/server solution for EDI processing
    wherein the server can reside on a VAX or Alpha and clients can reside
    on same, HP, IBM, more.  We sell ObjectBroker as a supporting layered
    product with every DEC/EDI sale.
    
    Transport modes can be DecNet or TCP/IP, with the latter rapidly
    becoming the mode of choice.  For further questions regarding this,
    please contact Mark Thompson @REO (EDIENG::THOMPSON).
    
    								Tex

    
    Other ObjectBroker success stories can be obtained from the product
    manager, Dan OOYES::GILFIX.
    

    The Navy PMS project is using Object Broker for a "three-tiered"
    solution.  Although, they are just using the RPCs instead of taking
    advantage of its object capabilities.  Don Moes is the technical lead
    on the project.
    
    Also, check with Yominda in your office, she has access to the number
    of licenses sold.

On the SEND node is a document called references.  At ObjectWorld, Wells Fargo Bank in 
California went public about a multimillion $ project they have done with Objectbroker.  

3-tier accounted for 5% of development projects in 1994, projected for over 30% by 1997, 
according to Gartner.

    As a follow on to the base notes question, can anyone contrast Object
    Broker with OEC's Entera?

re "On the SEND node is a document called references."

where on send:: ?

I tried send::r*
        SEND::OBB$PUBLIC:[000000...]r*

no luck?

thanks in advance,
Bob

    OEC's Entera is a series of development tools (most of which are extra
    cost above the base price) and a few simple management tools on top of
    either (1) DCE RPC or (2) OEC's "RPC lite." Entera uses a simple
    Interface Definition Language (IDL) that is a gross subset of DCE RPC
    IDL (only the most simple data types, etc.). With this one can simply
    and quickly build RPC servers and the clients that call them for
    relatively simple operations.
    
    ObjectBroker(tm) [please use it as all one word even if you leave off
    the trademark indication as only as a single "word" is it Digital's
    trademark) is a CORBA-compliant object / distributed object run-time
    system. It comes (in the developer kit form) wtih the necessary include
    files, IDL compiler, etc. to develop CORBA-style object applications.
    It supports the full CORBA V1.2 spec with some additions. Other
    additions, CORBA V2.0 elements, etc. are in the works. It also comes
    with a bridge to OLE so that CORBA servers can be transparently used by
    OLE desktop applications.
    
    /s/ MarkB

    re .9
Opposing OEC's Entera vs. Objectbroker
From the OEC's Entera characteristics :

>    IDL (only the most simple data types, etc.). With this one can simply
>    and quickly build RPC servers and the clients that call them for
>    relatively simple operations.

... One may then conclude that with Objectbroker one cannot simply and quickly
build servers and the clients that call them for relatively simple operations.

Am I the only one to think this is going to the opposite direction to the 
market trends requiring more and more simple and flexible distributed systems ?

Regards,
Jean
    

re .10:

No, you're not the only one.  I don't think it's 'just' market trends. 
Simple solutions are all we need and all we can afford.  The longer I
work in this trade the more convinced I am of that.

Nick

    
.10> ... One may then conclude that with Objectbroker one cannot simply
.10> and quickly build servers and the clients that call them for relatively
.10> simple operations.
    
    One may logically conclude that from what was said and unsaid in
    previous replies -- but one should not take that conclusion to the
    bank.
    
    One is invited to look at the fairly simple banking examples that are
    included with the ObjectBroker V2.5 kits. One may also look forward to
    a "quick start" feature in a coming release of ObjectBroker, which will
    allow simple operating applications to be created automatically from
    IDL, and which was convincingly demonstrated at ObjectWorld within the
    past few weeks.
    

    Regarding .10
    
    
    Modeling, building, and maintaining a clarge client/server based
    distributed system is a very complicated task.
    
    The CORBA standard/ObjectBroker implementation are intended to build
    such systems.  You can use it to build a small client/server system
    (say one or two object types) but you could also do this using SQL
    Windows, Power Builder, ... for a much less money.  Just don't expect
    such a system to scale.
    
    Even using CORBA, destirbuted systems are hard to build.  We, the
    colllective industry, are still learning the ins and outs of building
    such beasts.  As we internalize "typical customer requirements" we can
    then figure out how to elminate all of the knobs and buttons that must
    be dealt with at this point in time.  Our competition is in the same
    boat.
    
    CASE tools that address various aspects of the distributed system
    design process are appearing.  Here at Digital, the FBE team has
    put together a methodology and tool set to address requirements
    gathering, system design, interface specification and server 
    implementation.  This whole process is based on an extended OMT
    methodology that is front ended by Jacobson Use Cases.
    
    So, with reagard to ObjectBroker and its supporting tools, things
    are not bad at all.  Our competition is in worse shape and we are
    not standing still.
    
    David Glaser
    FBE Team Member
    
    
    
    
    
    

>    Modeling, building, and maintaining a clarge client/server based
>    distributed system is a very complicated task.

This is something of a religious issue with me, and I think I will point out
a few (overview) things about OO development from the IM&T point of view. I
feel somewhat qualified to speak on this, because I am one of the developers
of the R/3--ObjectBroker integration strategy & toolset. FBE is currently
using and apparently selling this strategy/toolset to external customers.

First, it appears to me, from some 17 years in IM&T, that rarely if ever are
new, large scale applications built FROM SCRATCH. Most (and I believe this
trend is increasing, due to cost constraints...) are either integrations or
modifications of existing systems, or are purchased; in either case, they
are medium-to-large scale "legacy" (or "heritage") systems. So the trend is
towards "wrapping" existing applications to provide "business objects" which
can be "integrated" in client-server links with other legacy systems.

I believe the IM&T work in "wrapping" existing systems, and integrating them,
FAR exceeds any work in scratch-building new applications. Thus, the oppor-
tunity for sales of Digital services is in system integration, NOT in new
design or building. 

>    CASE tools that address various aspects of the distributed system
>    design process are appearing.  Here at Digital, the FBE team has
>    put together a methodology and tool set to address requirements
>    gathering, system design, interface specification and server 
>    implementation.  This whole process is based on an extended OMT
>    methodology that is front ended by Jacobson Use Cases.

There is SOME value in front-end design of OO systems, but to do it in an
abstract way, (as in FBE's "Method F" Use Cases) does NOT address the needs
of the IM&T organization involved in integration projects. Clearly, the
legacy systems and their APIs already define the data and processing required
for integration. There is little point in modeling such things, because the
model is just a copy of the existing behavior. At best, an OO object and
method (message) is just the logical sum of the APIs implementing the method.
Obviously, if the existing APIs are not well documented, then "modeling" does
help in understanding the integration requirements.

But once the model is complete, where are you? Well, ObjectBroker can take an
IDL (Interface Definition Language statement) and compile it into C language
code modules and messaging/brokering definitions. The C language modules 
are, fundamentally, an RPC! Now you have to modify both of the "legacy" appli-
cations to fit the C module RPC. Then you have to install the messaging and
brokering definitions on the various network nodes where the system resides,
and once everything is debugged, a non-trivial process, you have a client-
server interconnect, and from what I've experienced, a pretty good one in
terms of performance, reliability, portability, etc.

That's the GOOD news. Here's the BAD news: if anything about the interconnect
that you've just implemented needs to be changed, you get to do the above
process all over again. The ObjectBroker object/method CANNOT be extended or
changed without overhauling all of the code from the IDL on. This is why the
FBE process emphasizes "carefull modeling". That's good, but it assumes that
the requirements of interconnects are STATIC, and once we've done the model,
nothing will change for a long period of time. Anyone who's worked in IM&T
for more than a week knows that's nonsense. Requirements change DURING 
development, and constantly thereafter. That's the nature of application
development: unlike developing a layered product, there are no standards, like
CORBA or ANSI C, to meet, and the requirements are NEVER "frozen". (And I
can say I'm glad to see that development methodologies have FINALLY begun to
recognize this fact, and adjust the so-called "system life cycle".)

So, for IM&T, the first issue is to wrap or modify ObjectBroker in some way
that makes it easier to use, faster to develop, and most of all, MORE FLEXIBLE.
Flexibility is the KEY to successful IM&T work, and particularly integration.
Flexibility leads to more rapid application integration, and less pain down-
stream, when everything needs to be changed. Flexibility is the only way that
tools can move IM&T organizations from point-to-point connections to true
OO strategy (And I believe this is a worthwhile goal, but seen by IM&T as
nearly impossible with existing technologies and situations).

So here are some things to think about, relative to the tools, and the OO
paradigm:

	OO defines objects as extensible via inheritance. This is nearly
	impossible in ObjectBroker, and method mapping does not really
	compensate for this lack. 

	"Simplify, simplify": Objectbroker does not follow Thoreau's advice.
	Method development involves numerous complexities which can be, to
	some degree, safely ignored, but this parsing process slows development
	and severely deepens the learning curve.

	For systems to build OO applications, the objects and methods must
	be in a clearly-defined library, and the contents of the library
	must be controlled. The Microsoft Foundation Class library is a
	reasonable example. ObjectBroker does not support this.

	Models which attempt to integrate existing systems must recognize
	that some poor coder is going to have to take some abstract concept
	and write it line-by-line in C to integrate with the legacy system's
	API, which may or may not be "open", and the coder will not be pleased
	to have to write 1000 lines of code to "force fit" some abstract
	model, with NO guarantee it won't change tomorrow. 

	IM&T (and all business, I would guess, to some degree) must be targeted
	on relatively short-term goals, one to two years. Long term goals are
	often stated, but IM&T recognizes that long term goals are the most
	vague, most difficult to focus on, and the most likely to change. OO
	is the darling of the industry right now, but will it be so in 5 years,
	or 10? So ObjectBroker and FBE must show IMMEDIATE benefits, not just
	long-term abstract benefits. 

	Finally, the IM&T application environment is highly dynamic. All levels
	of IM&T are looking for ways to do change faster and cheaper, in part
	because IM&T should provide "competitive advantage" by building more
	sophisticated and faster ways of conducting business, while at the
	same time minimizing demand for resources. This means that the era of
	pondering over analysis and design for a year or two before building
	a system is over. Analysis and design must be quick, easy to under-
	stand by users and developers, and it must be implemented rapidly and
	reliably with minimal complexity and most of all, MAXIMUM FLEXIBILITY.
	Sorry to say, in my experience, ObjectBroker and FBE are not there
	yet.

I say this in the spirit of hoping that FBE and the ObjectBroker development
team continue to improve their respective products. I have made, and continue
to make, one simple suggestion to engineering which develops tools used in
application development: You have a large, captive customer base: Digital's
IM&T. Do what we do: get down in the trenches with the people who use your
products every day, and ask them what's important. (Not that all their needs
can be met right away, but that you're constantly aware of them.)

>    So, with reagard to ObjectBroker and its supporting tools, things
>    are not bad at all.  Our competition is in worse shape and we are
>    not standing still.

David, I wish I could agree with the first sentence, but I don't. A lot of
improvement is necessary, and needed right away. Compliance to standards such
as CORBA is meaningless if no one cares about the standard, and it interferes
with getting the job done. What MATTERS is getting the job done, and minimizing
resource consumption now and in the future (maintenance). (Remember, most
"standards" came from some well-known need, and were de facto before they were
legislated.)

On the bright side, I think you're absolutely right in the second sentence. To
continue our lead, I believe ObjectBroker development and FBE consulting must
not focus on developing point solutions, but on the larger picture of making
ALL solutions easier, cheaper, more robust, and (one more time...) flexible.
    
John Osborne    

    John,
    
    there was a lot of signal in that noise from the trenches.
    
    Thanks for the feedback.  I'll share it with my co-developers.
    
    -David

    
    John,
    
    	I would like to repost this in the FBE conference if you don't
    mind.  A very useful set of requirements thanks! 
    
    	I would also like to spend some time showing V2.0 of FBE it
    addresses some of the issues you mention.
    
    Pete Hennessey
    FBE Engineering

    re: .14,
    
    John, you could repost that, replacing "IM&T" with "Prospective Digital
    Customer".
    
    Excellent!
    
    -Tom

re: .16
>    	I would like to repost this in the FBE conference if you don't
>    mind.  A very useful set of requirements thanks! 

Not at all. You know I've never been shy about sharing my opinion with FBE...

>    	I would also like to spend some time showing V2.0 of FBE it
>    addresses some of the issues you mention.

I don't have time to attend the course in Sept., but David Glaser has kindly
offered to send me the docs, and I will be talking to both of you. I believe
that FBE is really improving on listening and responding to their internal &
external customers.

Thanks, JO

    
    
    I need to contact the person responsible, or Unit Manager, for the Unit 
    that supports Objectbroker in Atlanta. We have had a number of problems 
    with regard to this product over the last month with a customer in London,
    thankfully, with the help of Engineering most issues have now been
    resolved.
    
    The problem we have, is that we need to set up some additional support
    for the customer once their system goes live, and Engineering pull out
    of the equation.  Presently there is no CSC support for this account -
    in fact, for any European account for this product, and it has been 
    reccomended that MCS set up a first line support via USA -CSC (Atlanta) 
    while the resolution of this issue is worked out.
    
    Please either reply to this, or mail me at KERNEL::MCGAUGHRIN, 833-3815
    
    Thanks
    
    Ian