|
Re: More on languages and objects
|
Posted: May 13, 2005 11:18 AM
|
|
> In particular, when > > we pass information from one process to another, we > > er, we would like to think > > of this as passing an object from one process to > > ess to another. > > > From your own admission - an object has both data and > code and much of what really gets distributed is > actually data (object state) and not code. The situations > that actually warrant behavior to be transmitted across > the network is but very rare.
With Java, it is mobile code that is important. The fact that code goes with the data means that you can dynamically change the granularity of network operations independently of the interface that the services are known by.
> So if the problem in distributed computing is relating > (read or write) object state to the network stream, then > shouln't OO languages have a well defined model > (representation) for object state. This model should > support reflective, dynamic and uniform access to data. > When this is absent you transfer the problem to the > application developer and thus end up with vague questions > about language-independent systems.
Serializing data across the wire is only part of the problem to solve in distributed computing. The more important issue is how to abstract away the service interface from the data exchanges and the transport and access to the data that is exchanged.
Web services and XML/SOAP don't let you do this because it is the specification of the transport layer and the data format that lashes down the interface. The Java RMI programming model, and the extensions of that model which the Jini platform provides through the Java Extensible Remote Invocation (JERI) stack, allow for decoupling. That is, the Java interface specification of the service is typically cast in concrete for any particular named interface. However, with mobile code, the implementation of the service might be local to the client, remote to the client, or distributed from the client to use multiple services and create the correct environment for the client to experience.
Web services can't provide this capability using only XML because everyone has to have their own implementation of the code that uses the data. Everyone has the same mechanism for getting the data, and must perform their own optimizations locally. With mobile code, the service implementation can be changed dynamically to further enhance the impementation, security and viability of the service.
This is what distibuted object models are really about from my perspective...
> So, OO languages should have a core data representation. > All user defined types then get support for extraction to > and from this core representation for object state. Once > this is available it finds use whereever behavior is > dependent on the state and not on the behavior in types.
You are not considering mobile code, nor the benefits of varied implemenations of the same interface in this view.
> Specifically network distribution, persistence, and > handling stream data formats are problems not related to > individual type definitions but rather to the internal > state representation in types. When you do not have a > model to represent state you cannot describe > relationships, constraints and operations on state. > > The question then is - how and when should you expose this > state representation of objects. Introducing this state > abstraction shouldn't change normal domain related > programming tasks.
I think there are some interesting questions here, but I am not sure that they apply directly to the issue of how a distributed object model, including mobile code with varied implementations, can work in a multi-language and multi-VM environment.
|
|