The Artima Developer Community
Sponsored Link

Weblogs Forum
More on languages and objects

23 replies on 2 pages. Most recent reply: May 13, 2005 2:18 PM by Gregg Wonderly

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 23 replies on 2 pages [ « | 1 2 ]
Chi Liu

Posts: 1
Nickname: chiliu
Registered: Apr, 2005

Re: More on languages and objects Posted: Apr 25, 2005 1:14 PM
Reply to this message Reply
Advertisement
Maybe it is why prefer service instead of object in the case of distribution computing where single platform/language is not possible.

Mike Petry

Posts: 34
Nickname: mikepetry
Registered: Apr, 2005

Re: More on languages and objects Posted: Apr 28, 2005 7:02 PM
Reply to this message Reply
I am not a Jini guy so I can't figure out where this discussion is going. Surely by now, with XML, XML-RPC, SOAP, SOA, we know that data models and implementations can be totally decoupled. Some of the technologies of the recent past have made this confusing by providing the ability to serialise interfaces and objects. Nobody needs the objects themselves, all that is need is the state of the objects. Object state can be handled by any language as entities such as structs, hashes, Records, or classes. The only real conflicting/competing perspectives are the perspectives of relational data and objects. If Jini is another way to serialise data between endpoints then Jini could do SOAP or even COM with custom marshalling. Is it just a form of RPC?

venkata subramanian m

Posts: 3
Nickname: annacoder
Registered: Apr, 2005

Re: More on languages and objects Posted: May 6, 2005 9:16 AM
Reply to this message Reply
in agent oriented programming, passing code is also very important....

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: More on languages and objects Posted: May 13, 2005 11:05 AM
Reply to this message Reply
> Rather than think of sendng objects across the wire, think
> of the wire as an object, with all the features of
> encapsultion, etc. Then code doesn't don't care what's on
> the other end, just what that wire-object returns, and how
> fast, and how reliably.

This is the root of the 8 fallacies of distributed computing. The code has to care because there are a whole set of failure modes of remote computing that don't occur for local computing.

One of the most powerful things about Java is the exception model. If, you are capable of abstracting remote failures into a model that is identical to local failures, then, your programming model can be more elegant. But, the biggest issue is deciding whether remote computing problems are transient or permanent with regard to the time span that you have to deal with the problem.

Remote computing related exceptions can be lumped into the realm of RuntimeException for the permanent failure case. But in both cases, the condition might be a transient problem that you can get past a short time later.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: More on languages and objects Posted: May 13, 2005 11:07 AM
Reply to this message Reply
> As to it being hard, I don't know for sure because I've
> never done a cross-language object model, but it's
> certainly doable. MS did it with .NET.

Microsoft created a virtual machine with as many commonalities of all languages as possible. Unsafe code not withstanding. It's the object model embedded in the machine that makes it work. The Java VM has the same properties, just fewer visible language mappings.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: More on languages and objects Posted: May 13, 2005 11:27 AM
Reply to this message Reply
> Another point that arises from reading the article, and
> nd also mentioned in most of the comments, is this - why
> must we use objects for distributed computing?
>
> I would like to take a step back and ask - What is the
> he task you are trying to accomplish using distributed
> computing? In short, you expect to pass some information
> to another server over the network and expect to get back
> some information in an agreed upon format. This format can
> be text, XML, objects, ..., but the key is that both the
> requester of the information and the receiver must agree
> upon the format.
>
> Jim's focus on using objects on either end of the
> the network reminds us of the old saying, "To a man with a
> hammer, everything looks like a nail."

From a perspective of a single language, you have a hammer. So, things that don't act like nails require more effort. It's the extra effort that I think is the issue here.

Does it actually make sense to exert more effort with the hammer, or create/use a different tool that only further divides the common platform/object model.

I, personally don't understand why people are so adverse to a single virtual machine standard that would encompass a single object/programming model. It would greatly simplify and empower software development to just get the job done instead of constantly solving the interworking puzzle.

Clearly Microsoft has finally caught onto one the VM idea with their copy (and devisively altered) version of the JVM technologies also known as the CLR.

What we have is people at the top levels of software businesses that still think the only way to get paid is to be different.

Making money from just getting the job done right doesn't seem to be a concept everyone understands yet...

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: More on languages and objects Posted: May 13, 2005 11:41 AM
Reply to this message Reply
> Well, syntax is part of language. C# and VB.NET are not
> the same language. And, thank goodness. If I had to type
> "MustOverride" in C#, well, let's not go there.

I think it's vital to understand the technology side and how this textual representation of instructions is not the totality of power in a language.

The indicated feelings above though, do convey how emotional some language preferences are... And if emotions drive the development of software systems, I fear that we will eventually have a language with a single keyword:

RUN;

and you'll order your version of the runtime from IBM and that runtime will be your application written in Java...

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: More on languages and objects Posted: May 13, 2005 2:05 PM
Reply to this message Reply
> I am not a Jini guy so I can't figure out where this
> discussion is going. Surely by now, with XML, XML-RPC,
> SOAP, SOA, we know that data models and implementations
> can be totally decoupled. Some of the technologies of the
> recent past have made this confusing by providing the
> ability to serialise interfaces and objects. Nobody needs
> the objects themselves, all that is need is the state of
> the objects.

It is the short sighted view that it's just the data that interesting which keeps one from understanding the benefits of Jini's remote computing model. The drive of web services has been primarily visible in transactional services where the data is exchanged for business operations.

Within the Jini platform, the concentration is on using services effectively. Tools are provided to make the hard parts of distributed computing with an object model much easier than if you just start from scratch. Over time, the web services standards have continued to adopt properties of the Jini platform as people become more aware of the issues that are actually present in a distributed computing environment.

> Object state can be handled by any language
> as entities such as structs, hashes, Records, or classes.
> The only real conflicting/competing perspectives are the
> perspectives of relational data and objects. If Jini is
> another way to serialise data between endpoints then Jini
> could do SOAP or even COM with custom marshalling. Is it
> just a form of RPC?

Jini is a platform that utilizes the RMI programming model to provide distributed service registration and lookup, distributed leasing, distributed 2 phase transactions, a Linda like tuple space known as Javaspaces, and through community projects visible on www.jini.org, many other tools and solutions for distributed systems.

Sun doesn't market Jini effectively because even those at the top of Sun don't "get it". The old messages of device communications are barren of the real simplifications/solutions that Jini can provide.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: More on languages and objects Posted: May 13, 2005 2:18 PM
Reply to this message Reply
> 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.

Flat View: This topic has 23 replies on 2 pages [ « | 1  2 ]
Topic: Coupling is not neccessarily a bad thing! Previous Topic   Next Topic Topic: Testing Invariants in C++


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us