Web Services Performance (WS-Performance) provides policy assertions that can be used to describe Web service performance characteristics and in particular provides set of metrics for already existing Web Services specifications. One of the most important concerns when composing Web Services is impact on performance of each specification. Therefore if there could be a synthetic indicator of performance impact of each specification it could help to automate estimation of composed Web Services performance and that is the role of WS-Performance to provide framework for such estimations.

This specification composes especially well with WS-Goodness to provide Web services that are both good and of reliable performance and although currently may be a bit slow (as all Web Services ...) but WS-Performance helps to estimate how fast (or slow) they are!

Reading a blog of such high quality as Chris Brumme where he is dissecting CLR internals in such depth (for example asynchronous operations) that it brings a joy to any engineers heart even if it is Java enthusiast.

I just can not stop to wonder where are Java blogs of such caliber that goes into such details and are written not by users but by creators. Java.net seems to be under control of "How-To" writers (exactly opposite to what Chris is doing), evangelists, SUN enthusiasts, and marketing specialists. Not exactly what I would call "The Source For Java(TM) Technology" and engineers seems to be lacking sorely from "a diverse group of engineers, researchers, technologists, and evangelists at Sun Microsystems" that was supposed to propel that site.

So where is SUN hiding all these Java engineers?

Please let me know if somebody knows where to find them ...

UPDATE: maybe other companies that also work on Java are more open? What about IBM, BEA, or other leading Java companies... ? Do their engineers blog (or are allowed to)? One has to admit that Microsoft seems recently much more open and interesting place than ever before ...

And unfortunately James Gosling posts about Zen and his grandmother even though very inspiring does not count as in-depth technical insights ...). And yes, I am impressed that this blog has now RSS feed (took only few weeks?).

If you need to add logging to your application without worrying about right version of log4j or commons-logging on CLASSPATH use MicroLogger. Just embed one logger class into your application package hierarchy (foo.MLogger) and either use it directly or do any tweaks necessary (source code is provided).

If a blog entry (such as my ramblings about memex) is long it will occupy too much space on front page or other summary pages. So it is good to break blog entry into "lead-in" and the rest of story.

I have it now implemented in MicroBlog by using a simple convention that if entry has empty paragraph it is used as place to break entry into lead-in and the rest.

This is mini review of "A Design Review of JDOM ( A Conversation with Elliotte Rusty Harold, Part III) ".

Let see how Xml Pull Builder a.k.a. XB1 (for more details on XB1 see its home page) compares to JDOM based on points raised in article.

A Short History of JDOM

Before we do this few word about XB1. XmlPull Builder Version 1 a.k.a. XB1 is lightweight document object model to represent XML tree that is implemented on to Common API for XML Pull Parsing and alpha version is in XPP3/MXP1.

JDOM Offers Many Convenience Methods

XB1 is currently rather modest API and do not have lot of methods (except for obvious overloading of methods) and that makes API quite simple (at least for now).

JDOM Allows Malformed Documents

XB1 implementation also allows creation of malformed documents or let put it this way: the implementation does not do extensive checks but XB1 API allows implementations that will do those checks (XB1 API is composed of interfaces). BTW: example with control characters is not good as XML allows to have control characters but escaped as numerical entities AFAIR ...

JDOM Ignores Setter Method Conventions

I do not see problem here: JDOM is not Java Bean and chaining methods may be sometimes convenient (but should not be overused). This looks like rather weak complaint ...

JDOM Uses Java Collections

XB1 goes one step even further and it uses Generics for even more natural iterators than mentioned NodeList (currently moving to use future java.lang SimpleIterator interface so idiomatic for(XmlElement el: node.elements()) will work in JDK 1.5) .

JDOM Uses Too Many Checked Exceptions

XB1 has only one exception (at least for now) and it is runtime exception for all reasons mentioned in the article and i woould add one more reason: RuntimeException makes it easier to integrate XB1 into existing code.

Will JDOM Remain Class-Based?

I agree that interface based API is more versatile as it allows to abstract form implementation and allow creating XML tree models directly from other data sources that XML event stream from parser (like databases)

Conclusion

I was disappointed that XPath integration (and good performance of it) was not mentioned. Also I would like to see some tests that compared memory footprint and how easy is to build partial tree: this is very easy with XML pull parsing but quite difficult with push parsing (in SAX it requires provide way to overwrite endElement() callback and in general is as much fun as writing SOAP deserializer with SAX). And as far as future of XML Tree APIs: I would like to see how easy is to annotate XML infoset items with additional information (needs for it emerges with data bindings and PSVI)

But after all what makes and breaks APIs is how programmers feel about them, and I feel good about XB1 when I am using it (nothing to do with the fact that I am author of it of course ..)

Xydra is a library that uses servlet to provide XHTML based WSDL invoker. Xydra servlet takes WSDL with XML Schema complex types as input, generates XHTML form to allow user to fill content of input message, gathers submitted input values and converts form name-value pairs into XML message that is sent it to Web Service and then finally displays result message.

One could ask: there are other WSDL invokers so what makes Xydra unique? Here is couple reasons:

• Xydra has pluggable data model and currently two backend to represent form and XML message content One is traditional name-value pairs that are structured into tree (called TreePath) and second that is based on Protege engine to use ontology describing web service to allow more reach constraints and relationship validation (called OntoBrew).
• It is very easy to customize Xydra look and feel: just save auto-generated XHTML page, modify it to your needs and tell Xydra to use this XHTML page as template. What makes it really easy is that template is a regular XHTML page that is used by Xydra processing engine (unsurprisingly called Diesel) to annotate it with runtime information.
• Xydra support complex types and generate nice XHTML form UI for arbitrarily nested XHTML forms.
• You get source code so you can improve it :-)

Sample installation is available online to test drive Xydra. It is open source so anybody can play with it, improve it, and give us feedback, patches are gladly accepted, we may even fix some bugs when reported (good bug report that contains all information necessary to reproduce problem and/or unit test greatly increases chances of getting problem fixed ...)

microBlog improved: finally resolved generating and linking pages for multiple categories and fixed category specific RSS feeds.

Talip Ozturk writes about J2EE and Jini and what is relationship between them:

(...)They are not truely competing technologies rather complementary technologies. if you are writing a J2EE server, you can use Jini's dynamic, self healing features. if a Jini service needs to persist data in a way that entity beans does, then the Jini service can make use of a J2EE server to do that. if you are writing JMS implementation, you might want to leverage Jini JavaSpaces technology. JNDI might internally be interfacing with Jini Lookup Service to gain some dynamic behaviour.(...)

I think that distributed computing is changing with advent of Web Services and in particular Grids. The feature may be something like distributed container that is dynamically created from available services (similar to Jini but on Internet scale) that guaranteed to have all required resources such as performance, bandwidth, transactions etc. as described in SLA, QoS, ... (in this respect it is meeting and superseding requirements of J2EE).

Anyway only future can really tell and some technologies seem to stay longer (or shorter) than predicted.

(...)Ok, so let's start to talk about the product: It is about SOAP Services. Actually, they still call it Web Services but in fact, it has nothing to do with the web at all. It is only about SOAP anymore - and it is only about SOAP as a framing format anymore. Frankly, I think that this is a very good thing: using HTTP in your mission critical applications might not be the best idea. Wouldn't it be way cooler if you could just take an XML document, wrap it in a SOAP envelope and send it over whatever reliable protocol you like? While still using all WS-* and GXA specifications?

this desription of WSE2 sounds like what WSIF except that WSIF has support for industry standards such as CORBA/IIOP and does not require to send SOAP envlopes.

However the problem with WSIF that it is only client side ...

Rants can be fun especially of they touch the gist of real issue, such as Hani on maven:

(...)No doubt that road will in turn lead to yet another tool to manage maven.(...)

If you build metadata driven build tool then better you make it easy for users, trying to fix tool by adding another tool with more metadata may not help ...

There are no developers working on this project. Please check back at a later date.

Great way to waste time if you happened to get to this page from google and not to much more useful old fashioned simple HTML page with kinds of info i need: documentation (just API - could be more but still OK) and release notes and nothing more!

As I have discovered after few hours of frustration support for versioning in Java is awkward and is based on Package Versioning spec that has only HTML description but does not have a working example (article in JavaWorld and working example provided were very helpful to figure out what was going on ...)

This is one of those rare moments that i wish i used other programming language than Java where they better solved this issue. for example it turned out that it does not work until at least one class from package is loaded into application and instead of trying to load package classes the API simply returns null exactly the same value if package is not available at all in current classloader - so the developer needs to guess why null was returned ...

My main problems are that it is only package based (i can always just version one package for library for simplicity) and it not possible to use API if code is not in JAR file and that is big problem. in such case Package.getPackage("package") returns not null but all calls to get getSpecificationVersion() etc. will always return null as implementation completely ignores my MANIFEST.MF even though it is on CLASSPATH but it is not in JAR file (one more reason to have real class metadata support in Java ...)

one nice thing i found is good and useful schema for assigning version numbers with MAJOR[.MINOR][.MICRO][_PATCH_NUMBER|-MILESTONE_NUMBER],

for example: 1.1, 2.20.1, 3.4.5_03, 4.5-beta1 (more details in notes about Specification-Version and very good rationale on not making implemntation versions comparable as described in Rationale for Limiting Implementation Version Numbers to Identity, excerpt:

A bug first appears in some version of a vendors package and may or may not continue to be a problem in subsequent versions. If the client of the buggy package uses a workaround based on version numbers, it could correctly work around the bug in the specific version. Now, if the buggy package was fixed, how would the client package know whether the bug was fixed or not? If it assumed that higher versions still contained the bug, it would still try to work around the bug. The workaround itself might not work correctly with the non-buggy package. This could cause a cascade of bugs caused by fixing a bug. Only the developer, through testing with a new version, can determine whether or not the workaround for a bug is still necessary or whether it will cause problems with the correctly behaving package. The developer only knows that the bug exists in a particular individual versions.

current solution: define package.Version.check(String version) (example in XSOAP) and not waste more time on it ...

better marketing that is what really matters. example?

my minilogger has nicer syntax as it does not require class parameter to getLogger() so less redundancy and no need to do this awaful redundancy (and that is typical pattern in code that uses Log4J):

public class Xxxxxx {
  private static Logger logger = Logger.getLogger(Prunable.class);

public class Xxxxxx {
  private static Logger logger = Logger.getLogger();

i love XML Pull Builder API and it may not be good sign as i am its author ...

Anyway, this is second reincarnation of XPP2 XmlPullNode but this time done with all very nice decomposition into interfaces and value objects and both really easy to use (no longer prefixes or raw XML names are required) and really fast and powerful - essentially can be as fast as streaming pull parser as user can for part of tree work with pull parser directly :-)

The API is modeled after XML Information Set and allows building incrementally XML trees from events streamed from pull parser (user can start navigating tree before whole XML input was parsed!) and has an unique ability to bypass tree building for selected sub trees to work directly with underlying event stream. This coupled with ability to create XML tree that can mix in any Java Object allows to represent objects derived from XML (databinding) in the XML tree.

The unique feature of API is ability to achieve high performance that is common in streaming parsers and ease of use associated with tree approaches in the same API by provising very precise control over XML tree creation and access to underlying streaming parser during tree creation (API users needs to do it if and only if they do want to bypass default tree creation and replace it with their customized object tree, work directly with XML events or just skip unneded parts of XML that do not need to be in XML node tree).

Now the challenge is how to do it in C++ and to make it easy (especially memory operations) so it can favorably compare to DOM ...

• organize imports: when multiple imports are possible let user choose (and not show dialog that multiple choices are possible ...)
• more powerful completion that will search all classes and not only what is imported (so it can work with Ctrl-O and no need to leave import package.*)
• multiple run parameter sets - so i can configure different set of parameters
• allow to execute any JUnit test or even one method from TestCase just by selecting it by mouse

A constant for the current class instance

We have this but why not a thisClass?

Its a PITA to have to cut and paste class names when they could easily be a compile time constant. e.g.

public class Foo {
    private Logger log = LogFactory.getLog( thisClass );

instead of

    private Logger log = LogFactory.getLog( Foo.class );

which can lead to cut-and-paste errors. This is a common issue with using static methods in a generic way.

This is a very trivial change.

    private Logger log = LogFactory.getLog();

• organize imports (Ctrl-O) should give choice when class can be imported from multiple packages
• add extended completion (Ctrl-Space?) that would allow to lookup classes that are not yet imported. right now i have to write class name from memory and then do Ctrl-O as thanks to Ctrl-O i have no longer import * declarations ...
• dependencies between projects: so i do not need to have long list of all projects source trees but instead can say current project depends on project Foo and Bar and when CG5 compiles current project it will check dependencies and compile a dependent project if needed and then add automatically to CLASSPATH dependent project .class output (and related libraries)
• project settings/classpath management: needs ability to add multiple source tree or jar files AT ONCE!!!