How does object-by-value work ?
Marek Mosiewicz
It is easy to send attributes of object to client, but how client can
invoke methods of that object ?
Does client have to have it's own code of method implemetation ?
--
Marek Mosiewicz
Marek Mosiewicz
Steve Vinoski
news:Jwkk5.9537$FO3.2...@news.tpnet.pl...
In general, yes, the receiver needs to have its own implementation, though
with Java, there's a way for the receiver to download bytecodes for the
implementation (not sure how many ORBs actually support that, though).
--steve
--
Steve Vinoski vinoski at iona.com
Chief Architect 1-800-ORBIX-4U
IONA Technologies, Inc. Waltham, MA USA 02451
200 West St. http://www.iona.com/hyplan/vinoski/
Copyright 2000 Stephen B. Vinoski. All Rights Reserved.
Michi Henning
> "Marek Mosiewicz" <ek3...@capella.ae.poznan.pl> wrote in message
> news:Jwkk5.9537$FO3.2...@news.tpnet.pl...
> > I would like to know how it is possible to send objects by value in CORBA
> > It is easy to send attributes of object to client, but how client can
> > invoke methods of that object ?
> > Does client have to have it's own code of method implemetation ?
>
> In general, yes, the receiver needs to have its own implementation, though
> with Java, there's a way for the receiver to download bytecodes for the
> implementation (not sure how many ORBs actually support that, though).
None, as far as I know. (I'm sure that someone will correct me immediately
if I'm wrong ;-)
OBV with operations really only makes sense if you can tigtly control
the deployment of the application. If you know where all the clients will
be and you can dictate how these clients will be built and installed, you
can make sure that the relevant code for the OBV methods is available in
all the clients. Otherwise, OBV with methods simply doesn't work.
In general, I would avoid OBV with methods -- the idea breaks many of
the CORBA transparencies, in particular, implementation and language
transparency, because the IDL for the object is no longer the *only*
contract between client and server. Instead, client and server must share
some common understanding of what the methods do and how to implement
the behavior of the methods.
Cheers,
Michi.
--
Michi Henning +61 7 3891 5744
Object Oriented Concepts +61 4 1118 2700 (mobile)
Suite 4, 904 Stanley St +61 7 3891 5009 (fax)
East Brisbane 4169 mi...@ooc.com.au
AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html
Srdjan Stakic
>
> I would like to know how it is possible to send objects by value in CORBA
1) "object" is not a CORBA object (not a remote), but a local object in more
traditional sense
2) object graph gets transformed into a linear representation, and reconstructed
at the receiving context. Works with arbitrary object graph, cyclical
included.
> It is easy to send attributes of object to client, but how client can
> invoke methods of that object ?
> Does client have to have it's own code of method implemetation ?
Depends. If both contexts are on compatible platforms (i.e. ELF on Intel
architecture), some code sharing can be done, like:
- loading shared code from a dynamic library within NFS
- lazy code transport via some network protocol
If contexts are on different architectures, you will have to wait for some time.
I think that Ron Resnik suggested canonical code transport in form of Java
bytecode, which coupled with JIT is theoretically feasible. Also take a look at
dynamic binary translation (ACM Comm as of few months ago).
Philip Lijnzaad
Marek> I would like to know how it is possible to send objects by value in CORBA
using valuetypes, and a CORBA 2.3.1 compliant ORB.
Marek> It is easy to send attributes of object to client,
yes, they get there automatically. They are however not called attributes,
but members (to avoid confusion with attributes of a CORBA object, which are
in fact shorthands for get- and set-methods).
Marek> Does client have to have it's own code of method implemetation ?
Depending on whether the language has provisions for downloading code, no, in
principle not. But so far I haven't seen working examples of automatically
downloaded code, and it was easier to provide a local implementation by means
other than CORBA.
Incidentally, many (if not most; supporters of valuetype methods, speak up!)
people consider the presence of methods in valuetype the _worst_ design
decision ever taken, for the following reasons:
- IDL used to be a language to describe the server interfaces, but valuetype
methods _prescribe_ client behaviour, which is entirely inappropriate and
unnecessary (a similar argument applies to the private/public keywords:
they are none of the IDL's business)
- valuetype methods break language independence: no longer can it be
guaranteed that a client in any language can contact your server and
interoperate, simply because the server may happen not have, or know, the
code to download.
The first point is more relevant if code _cannot_ be downloaded (which is the
usual case), the latter is more relevant if it can be downloaded. So my
advice is to steer clear of methods (and interface inheritence) in
valuetypes. The only thing that valuetypes do seem useful for, is with using
inheritence from other valuetypes, thus offering a kind of extendible struct.
Good luck,
Philip
--
When C++ is your hammer, everything looks like a thumb. (Steven Haflich)
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk \ European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53