|
 |
Tuesday, September 24, 2002 |
Unique URLs. It's surprising to me how most bloggers could care less about their domain name. It would drive me absolutely batty to have a number as the sole identifier of my weblog. It also drives me nuts that other people don't seem to care because when I'm checking out referrers, I'm having to start to remember who's number is who's. Is this the 1970s? [Russell Beattie Notebook]
Totally agree. I hate the auto-generated Radio URLs. I mean really, my URL's http://radio.weblogs.com/0112098/ how sad is that. Even I can't remember it and its my site! :-)
I've no idea why it can't be http://radio.weblogs.com/james/ or something easy-ish to remember. My old Manilla blog had a simple to remember URL, http://james.weblogger.com which I miss.
3:36:17 PM 
|
|
Asynchronous services [FINALLY] preached.
In a recent article from infoworld: Next-Gen Web Services: Asynchronous services preached
People are finally realizing that Document or Message passing style is the way to go if you want to achieve interoperability in webservices. That's why I've been saying for so long, that the current Web Services specs like WSDL are woefully inadequate and plain wrong. WSDL is modeled after CORBA's IDL, this assumes RPC style messaging. Furthermore, all the toolkits out there support WSDL based code generation, unfortunately its not that useful for document style messaging.
The problem with the RPC style messaging is that it couples in time the parties involved. In otherwords, the parties have to be both present and active to get the communication across. It's okay for realtime processes, unfortunately most processes don't happen in realtime.
The wonderful idea that Linda Spaces (circa. 1980) brought to the world ( JavaSpaces is an implementation of Linda Space) was that it decouples server and client both in space and time. What does decouple in space mean? Well that just means that who communicates to who is not hardwired but discovered dynamically.
So until I see Linda Space mechanisms introduced in the Web Services arena, I'm not going to take it seriously. You can't just reinvent CORBA with an XML protocol and magically have interoperability. I do agree that XML makes it easier to interoperate by standardizing at least the syntax of messages and providing tools to parse those messages. However, I can't see what the Web Services protocol stack brings to the table.
[::Manageability::]
Agreed about the need for asynchronous, loosly coupled web services. Though you don't need to wait until Linda Spaces are brought into the Web Services worlds, you can just use asynchronous web services today then choose either email or JMS to send and receive them.
I particularly like Robert Marcus's point that as an industry we could really do with a standard, secure, web-enabled protocol for asynchronous messaging. So far I think HTTPR is probably the closest attempt. While we're talking about it, does anyone other than IBM actually use HTTPR?
Incidentally, since you mentioned Linda Spaces - have you seen Ruple? Its probably the nearest thing to a web service version of Linda Spaces I've seen so far. It sounds kinda cool though I've no idea what I'd use it for :-)
I guess thats the issue I've got with Linda/Java/Tuple spaces. They seem cool and groovy, but if I wanted shared memory I'd use a database (maybe with some distributed caching), and if I wanted messaging, I'd use a real messaging system.
Linda/Java/Tuple spaces seem to me like a groovy hybrid in between databases and messaging systems being a kind of jack of all trades and master of none. Though the best thing about Linda/Java/Tuple Spaces is that they're really easy to use.
2:33:58 PM
|
|
Weblogic Workshop's native XML scripting.
Found this article: Native XML Scripting in BEA WebLogic Workshop while browsing through Lambda the Ultimate.
I like XML literals are used to create XML values, just like numeric and string literals are used to create numeric and string values. This eliminates the need to invoke an XML parser or use DOM methods to manually construct an XML value by inserting nodes into a tree structure.
Although, aside from the XML literals, working with the Jaxen api, is just as convenient. This is something that's a very nice idea that we should incorporate in other scripting languages.
Another older idea in the train of thought was XDuce. In XDuce, variables have a kind of XML type that ensures that you always create schema conformant documents. [::Manageability::]
Another idea is to embed scripting languages inside the XML, such as with Jelly. Then you get to use XPath via Jaxen, have access to easy parsing of XML literals, can easily invoke XSLT whenever you need and can reuse existing scripting languages rather than writing another one.
Plus once the SOAP invocation library is complete, you'll be able to do some funky SOAP scripting too...
11:57:13 AM
|
|
ClassLoading, differently. It's not quite ready for prime-time, I don't think, but James Strachan already blogged me, so I might as well blog myself. I've started classworlds, a new project to hopefully help rid ourselves of classloader psychosis once and for all. It effectively turns the ClassLoader tree hierarchy into a directed graph of ClassLoaders. Effectively, a ClassLoader can have multiple 'parents' from which it can load classes. The relationship between ClassLoaders can be constrained to only allow classes belonging to certain packages to be loaded across ClassLoaders. Effectively, you get fine-grained firewalling with a sort of mix-in flavor to it. classworlds... [bob mcwhirter]
Sorry for jumping the gun bob :-)
What'd be really cool would be to plug in an implementation of ClassRealm that uses a refactoring of the code in Maven which automatically downloads jars from remote repositories if needed and then class loads them from your local repository.
Then if we could embed the dependency information in each jar we build via Maven (which would be a fairly minor patch, since Maven already knows the full dependency information), then it could autogenerate the ClassRealm required and auto-load all dependent jars automatically. Now that would totally rock... :-)
9:53:37 AM
|
|
Hot Anal Java!.
How about this for the worst product name in the Java space? Javaanal: Java documentation analysis utility![rebelutionary]
It does quite suit the application, though.
- It's for examining Javadoc coverage, but it's written in Visual Basic, and hence single-platform.
- It works by looking at the generated HTML instead of the source, so if you've got a non-standard doclet, it'll fall over and die.
- It presumes to recommend word counts for Javadocófrom 200 words per interface definition to 10 words for each instance variable. This just reinforces my belief that Javadoc coverage tools don't encourage better documentation, they just encourage more documentation.
- From the disclaimer: ìHCi Consulting Pty Ltd would like to warn potential users that this product may provide misleading, dangerous, and just plain silly results if not used by our staff experts.î In other words, ìIf you're stupid enough to use this tool, you'll probably want to pay us for consulting, too.î
[The Desktop Fishbowl]
LOL! :-)
Why they didn't just use a doclet is beyond me. For Maven users there's the Checkstyle plugin which can do the same thing, warning of missing javadoc comments etc.
Which reminds me of another IDE related rant. I really hate it when IDEs automagically generate comments for methods (often bean getter & setters). What's the use of an autogenerated comment? Its worse than no comment at all as it means automated tools can't find missing comments. Usually the autogenerated comment tells you nothing you couldn't already guess either.
9:46:20 AM
|
|
O/R talk today.
The blogsphere is a buzz with O/R talk today. You can checkout topics on rebelutionary or Joe's Jelly I think Anthony make a valid point about all these tools require or expecting you to change you data model...
...Changing your data model because your application code changes seems like putting the cart before the horse. Your data model should be well thought out. Any changes to the data model should also be well thought out. This is especially true when multiple applications share access to a database. Changing the data model because of one application's changes is extremely risky.
I've actually heard this time and time again, but I still don't buy it. This is our programmer laziness coming through, and it is one area where I believe we should not be lazy.
[All things Java]
This was the reason I wasn't to happy with OJB. It require a whole bunch of new tables to be added to the database. Several other project seem to only consider new database no existing legacy systems. You can see this, when it impossible to define the object based on select statement. I tried to see how to do this in both Castor and Torque, but either not possible or not documented. This brings up a huge problem with both of these projects. Lack of good documentation!
[A cup of joe]
FWIW I'm using OJB and it adds 3 tables, 2 for primary key generation and 1 for distributed locking. I don't need the latter since and I'm mostly using Oracle anyways so I could probably do without any of them ;-). Though OJB supports pluggable strategies for things like primary key generation and locking, so I could always switch in a new Strategy that doesn't use new tables (though it'd probably be using new Oracle sequences anyways).
I think most O/R tools can just reuse your data model without major change - it just might take a bit of work to do it.
7:20:42 AM
|
|
We've all done it before I guess. Called Class.forName( "com.foo.MyClass" ) to load some class at runtime based on some configurable class name. At first it seems very groovy.
However this does not work very well in application servers, containers or various environments like Maven, Ant, JUnit etc. The days of everything being in the system class loader are over, now we need to live in a multiple-classloader world.
Solution? Try use the current thread's context class loader or the class loader used to load your code. So try replace this...
Class theClass = Class.forName( className );
with this more verbose version (which could easily be wrapped in a helper method)
Class theClass = null; try { theClass = Thread.currentThread().getContextClassLoader().loadClass( className ); } catch (ClassNotFoundException e) { theClass = getClass().getClassLoader().loadClass( className ); }
Henri, this could be a possible addition to commons lang?
While we're talking about living in multi-classloader worlds, bob's new project ClassWorlds looks very groovy.
7:17:33 AM
|
|
© Copyright 2007 James Strachan.
|
|
|
