|
|
Re: Visualizing Complexity
|
Posted: Nov 20, 2003 6:45 AM
|
|
Software visualization is something that is available in lots of ways. At AT&T Bell Labs, they had a software visualization system that was intended to allow code complexity and breakage. It showed you where in the code the most bug fixes had been done, the relative age of the lines of code, and you could take a particular modification request (an SCCS MR of sorts) and ask what code did it touch.
This same system was used to visuallize the 5ESS ODB as well. It told you about references between tables, drew graphs of dependencies, and could diagram key dependencies. It was truely fastenating.
The great thing about this tool set was the extreme simplicity of the meta data. Each attribute that was to be considered had a directory tree. Under that tree was a directory tree that mirrored the original source tree. In that tree were files by the same name as the source. Those files just had markers on the same line numbers as the source file,where that attribute applied.
So, you could go from relationship to source line instantally and provide some very powerful zoom and and drilldown visuallizations.
There are still apparently a lot of people that don't understand what Jini is about. It bothers me that James didn't use the 'Jini' word in the following comment.
>So philosophically, I really don't know. Dealing with
>dynamic systems with pieces that come and go is a really >hard problem. There are all kinds of specialized solutions
>for specialized situations, but I've never seen anything
>like a set of general solutions. In some sense, this
>particular problem feels like one where unreliability may
>be a good thing, just because it makes the whole
>enterprise possible. Maybe people should just get over it.
The Jini infrastructure goes a long way towards solving this exact problem. It provides the UUid value that provides a 'forever' reference to the object. The use of multicast lookup means that a service can appear on any host, and the use of unicast lookup means that you can extend your services into other networks and allow distant clients to locate these disparetly located services.
More importantly is the fact that the contract between client and server is typically at the Java interface level. Thus, the client can just look for something implementing that interface if it needs a generalized service. If it needs a singleton, it can use the Uuid as a starting point. If it needs Authentication and Authorization, the Jini2.0 infrastructure has direct support for X.500 and Kerberos certificates. It also has pluggable Authentication capabilities. I've used this to provide access to linux servers using login information, via PAM, on the server. So, I can put accounts on that server, add policy for the service, and presto, a user providing those credentials (as PAM dictates), gets to use the system how the policy describes.
|
|
Previous Topic
