Frank Sommers
Posts: 2642
Nickname: fsommers
Registered: Jan, 2002
|
|
Re: Why Dreams of Jini
|
Posted: Mar 17, 2002 2:43 PM
|
|
> Jini isn't really for the web, it is for local
> networks. Bill and I were just discussing doing
> distributed gaming with Jini. Bill subsequently
> discovered (via the Google lookup protocol, no doubt)
> an article:
> http://www.sys-con.com/java/article.cfm?id=1357.
> However, the thorny issue of denial of service
> e attacks came up. In a local network, this is not
> a big issue, but if you have Jini services that can
> go anywhere on the internet, you have a problem.
Yes, but that's a problem for any sort of distributed system. I think the heart of DOS attacks lies in a lower layer, on the level of packet routing -- as long as you flood a host with packets, that host will at some point became unavailable for further processing, if for no other reason that the network leading to it saturates (or the node's processing capability is overwhelmed, or its memory fills up, etc.) With Jini, mobile code just ads the extra twist that a VM can't negotiate with a service as to how much code it's willing to accept, etc. That sort of capability should, in my opinion, be addressed on the class loading level.
As for Web services, I certainly think that Jini is a Web-services infrastructure. The W3c organized a symposium about a year ago, with the aim to try to define Web services. The interesting thing is that they couldn't come up with a clear definition -- certainly, the use of XML is *not* a prerequisite for a software object to be called a Web service (http://www.w3c.org/2001/01/WSWS).
Actually, I think it would be hard to see why someone would like to do distributed computing outside the context of the Web (by Web, I really mean the Internet). It's similar to people talking about client-server computing -- nowadays, "client" means a browser, and server implies an application server. I could hardly imagine someone proposing a "client-server" application without that implicit meaning (e.g., proposing a VB client talking to an Oracle database). In fact, traditional "server" applications, such as DBMSs, have really evolved into application servers, and traditional "client" tools, such as VB, have evolved into browser-like components. Anyway, I think it would be a hard sell to propose Jini as anything other than a Web services infrastructure. Many people just wouldn't see the point.
In fact, one of the big selling points of Jini is that it defines a Web services infrastructure, not simply an architecture. Every Web services architecture will, sooner or later, need an infrastructure as well. For example, how else do you manage stale entries in UDDI registries? How do you coordinate distributed transactions? How do you facilitate asynchronous message exhange? Remote events? All these things are issues that, sooner or later, any Web services system will have to provide for. Jini already defines these, so it's way ahead of other infrastructures.
Just to make one more point here, about Jini's specificity to Java. The .NET folks are making a whole lot of noise about their system being "language independent." Well, that claim, in my opinion, is meaningless. Distributed computing means *computing* -- at some point, somewhere, code must be crunched by some processor, and all data that code needs must, at that point, be represented in a programming language (or machine bytecode) that a (virtual) machine can crunch. For instance, in .NET, there is a "wizard" to convert a WSDL document to a C# stub, and interacting with a Web service, in fact, happens on the level of a VM that runs the C# code. Or, I heard that IBM has a tool somewhere on AlphaWorks that can take a WSDL file and make RMI-like Java stubs from them. So, again, an infrastructure *has* to facilitate the language-specific binding of data, otherwise that data can't be part of any computation. All Jini says is that APIs are easier for *programmers* to work with, since they define a specification in terms of a computation model (in terms of programming language constructs), whereas having to use some non-programming language construct to define a computation, and then convert that to a programming language, is more arbitrary. And Jini assumes that such artibrariness is not acceptable for large-scale distributed systems (i.e., the Internet), where there will be so many components that humans can no longer hope to stay involved and mitigate abiguity. So, in that sense, Jini explicitly addresses the needs of large-scale, global distributed systems, i.e., the Web.
|
|
Previous Topic
