Iain Shigeoka

Hi all,
I thought I'd pop in and add my own comments. Up front disclaimer: I'm the Manning webmaster, although not involved in this particular book project directly (other than supporting it on the site).
We're in the middle of migrating much of our site from an old, existing php system to Java (why the migration is occuring in the first place is fodder for another discussion). Just before the book was published (but after it went to the printers) the publisher asked me to check out Tapestry as an interesting technology for use in our site. I'd heard of Tapestry but never gotten past the front page at Jakarta Apache. So many frameworks, so little time.
I grabbed the ebook and sat down with the intention of seeing what Tapestry could do for us. I read some parts, and skimmed over a lot of the details so I could just absorb a high level "how it works and what it does". In that sense, I feel the book really succeeds. It's clearly written, and it sells the framework and demonstrates how it benefits a development effort. Being the first and only book on the framework, I think there needs to be this kind of coverage - people like me who don't know much about the framework need to be sold on it as much as educated on how to use it. I walked away from that first evening reading excited about the technology and eager to dig into details and try it out.
I also realize that it's a potential downside of the book (and Gregg points that out), it does sell the framework a lot. And I agree that the title may not be the best. The "In Action" series tends to be a lot more practical and focused. I also was struck with the steep learning curve introduced - actually several rather large steps throughout the book. The first comes with Chapter 2 where the general chapter 1 overview jumps right into a complete Tapestry application. After some discussion Howard produced a "Hello World" example that helps to bridge the transition and we've posted that on our website. Unfortunately the book was already being printed so it couldn't be introduced into the text.
The final book example takes another big jump in complexity introducing a pretty big tapestry application that uses most tapestry features, and utilizes EJBs for persistence. The examples assume the reader is familiar with EJBs so the entire persistence side is largely glossed over. This can be a rather harsh assumption since EJBs are complex, and the many EJB dedicated books show that EJBs aren't a trivial technology to master (even at a simple application level). On the flipside, for those of us looking to get a feel for Tapestry, and for architects and designers, the EJB example really helps to show how Tapestry's various components are used within an EJB environment (which is much more realistic but very complex).
My feeling is that TIA is a little bit of a tutorial with a lot of advanced (tapestry under the hood stuff) and designer/architect level content. Manning usually publishes books at the intermediate to advanced level and I think we may have hit that mark but shot too high for the existing market with this first Tapestry book - it's going to be hard for novices to get up to speed with using Tapestry with this book alone and there are probably a lot more Tapestry novices (or people looking to become Tapestry novices) than experienced users out there. The full spectrum coverage helps evaluators and planners immensely and tries to provide advanced Tapestry developers with a lot of very valuable information in tinkering with Tapestry. As a how-to tutorial though, the book does have shortcomings.
I like Gregg's suggestion that the title should have been Tapestry Under the Hood. Or my suggestion of Advanced Tapestry. They're probably more accurate and with that title, would probably have set expectations properly for what is an excellent (if mistitled) book. Unfortunately, since it's already in print, changing the name is difficult. Perhaps a focused introductory book on using Tapestry should be on the Manning roster.
-iain

Thanks guys.

Congratulations and thanks for participating. I'd appreciate it if the winners (anyone who has the book actually) would write a review at amazon about the book if could spare the time. Believe it or not amazon reviews really affect sales.
Thanks again.
-iain

Oops. I should note that my doesn't cover Jabberd other than in passing. Instead, I concentrate on the protocols and how you can implement them in Java.
If you're interested specifically in Jabberd configuration, you really want to buy/inspect Programming Jabber: Extending XML Messaging (O'Reilly XML) -- by D. J. Adams.
-iain

Check out http://www.manning.com/shigeoka
-iain

Originally posted by David O'Meara:

What do you mean by zero-knowledge? Are you refering to a proprietary protocol where the security is based on intermediate viewers not knowing how to read the data?

The zero-knowledge authentication scheme for Jabber is unique to Jabber (invented for Jabber use). It basically works by establishing a standized pattern for password generation. The client starts by telling the server the first password, and some data that is used to generated it. This pattern involves a standard way for generating the next password in the password sequence without knowing what the previous password is (digests of digests).
The next time the client wants to authenticate, it sends the previous password, and the server confirms it by taking that previous password and generating the next password (the one it should have stored). If it matches, the server stores the new previous password as the current password and throws out the old one. So I guess its more accurate to say that the server only stores a one time use pasword that is immediately invalidated once it is succesfully used.

What about emulating the standard HTTP authentication mechanisms, password digests (ie one way functions) being the obvious exclusion...
You could make use of SSL to encrypt clear text password transport, but if you're working in a client/server world where you control the client and the server, digests would be a simple inclusion.

There is currently work underway to switch Jabber over to using SASL for encryption and authentication. All the internet protocols are moving over to SASL so I think this is a great move and essentially achieves what you are suggesting. SASL is a pluggable security system and is being adopted for HTTP, POP, etc. Check out the ietf (www.ietf.org) for more info on it.
-iain

Jabber server configuration is very implementation specific. You have to consult the documentation for the particular server you're using. if you're using jabberd from www.jabber.org there is a mailing list and several guides dedicated to answering these questions.
-iain

There is no official binding for Jabber over HTTP. However standardization work is underway and I think Jabber Inc (www.jabber.com) has implemented it for some of their clients. So it is possible but not widely available.
As for security, Jabber provides three authentication protocols: a simple plain text password, a digest based on stream ID, and a zero-knowledge protocol where passwords are never sent across the network and are not stored on the server (pretty secure). in addition, you can connect to a Jabber server using SSL. However, as discussed in other topics here messages are not secured from the server so you must trust all servers. Clients can get around this by encrypting messages to be sent. This protects the message but still allows the server to know who you're sending messages to and how big they are.
-iain

Originally posted by Juanjo Bazan:
I would like to know what are the main points to decide wich protocol i have to choose to build my messaging app, and the pros and flaws of every candidate protocol.
[ June 19, 2002: Message edited by: Juanjo Bazan ]

It would be pretty hard to do a comprehensive survey. There are dozens if not hundreds of protocols that already exist or are being developed today.
In evalutaing I'd probably ask the following questions:
What network will I use? If you have tcp/ip you can use sockets. If you have Java at both ends you can use RMI. However you may be stuck with HTTP only, or SMS, etc.
What clients will be used? Do you need to support embedded devices? Desktop clients? Web clients?
Do you want/need/can afford to have a server? You can use peer-to-peer technologies if not (gnutella, JXTA, etc).
What level of security do you need to have? Some protocols give you better security than others.
What level of reliability do you need to have?
Can you afford to pay for your solution? There are some open source alternatives but many of the high end ones are proprietary.
What kind of data do you need to pass over the IM network? Streaming media files? Large data sets? Or just simple text chat?
Do you need to have multiple vendors for solutions? Open source like Jabber has some advantages here but other comomn technologies exist such as Java Message Service (JMS), CORBA, etc.
Do you need to have commercial support?
Do you need to integrate with other desktop or server infrastructure. Like it or not MSN Messenger and Passport is well integrated into MS products and has a lot of advantages in that light (like integration into Outlook). Yahoo messenger can integrate well into their other web offerings, Lotus IM and Domino, etc etc.
Once you answer these questions, you can start to evaluate the alternatives and narrow down the field to some small enough group to do indepth research and take it on some trials.
Sorry there aren't easy answers for this one.
-iain

JDOM vs SAX
For servers SAX is probably the way to go as it is fast and efficient. However, clients will be network or user bound (waiting for i/o) so the efficiency of parsing and representing data isn't very critical. In this case, developer efficiency rules.
If you haven't already, take a look at JDOM (www.jdom.org i think). It's basically DOM customized for Java so you can do stronger type checking and it follows Java library conventions for collections, iterators, etc. making it easier for most Java developers to use.
In the Jabber protocols you will be sending and receiving XML 'packets' which are sub-documents of the larger XML stream document. Each component in the client will handle each of these XML packets as relatively independent data. It is handy to develop clients with an event architecture with the XML packets serving as events. This plugs in well with the Swing event model too.
When you use SAX your events are the individual, low level XML information such as start tag, end tag, character data, etc. In most cases, you will end up building a class or data structure which is very tree like. In servers it is worthwhile to go through all sorts of contortions to make these XML packet objects as efficient as possible (sharing strings to reduce object churn, optimizing building and recycling of these objects, etc). On the client, this isn't such a big deal so you might as well let JDOM build you a generic JDOM document and use that as your packet object.
This doesn't eliminate the need for "framing" up these sub-documents so the XML parser (JDOM or SAX) treats them like separate documents. This takes customization of either the stream feeding the parser, the parser itself, or the JDOM document builder (or your own custom object builder class). If you read my book, you'll see how I did it with SAX, custom object builder classes, and custom packet objects. If I were writing a client library, I'd probably use a pull-parser like the embedded pull parser from www.enhydra.org, and design a custom JDOM builder class.
Basically, my argument for using JDOM is laziness (i.e. lazy as a programmer virtue... see Perl, or old unix programming books for why this is such a great thing). Being lazy in the right ways usually leads to better libraries.
Jabber clients and foreign protocols
In general, Jabber clients don't need to do anything to support foreign protocols like AIM. Bridging to these networks and translating data formats are jobs performed by the server in most cases.
However, some systems like AIM have been blacklisting Jabber servers by watching how many users are logged in from a single IP address and blocking those that exceed some limit (a good sign that a Jabber server is at work). So some client authors have been writing their clients to hande foreign IM systems. However, AIM has been pretty good at doing things like asking for message digests of their client's DLLs and other things to make sure that you're only accessing AIM through AOLs client. It's kind of a losing battle unless you really want to devote a lot of time to fighting AOL.
Most other systems though tolerate some bridging and for those, there is usually Jabber server support (Yahoo for example). And truly open systems have excellent Jabber server support (IRC for example).
-iain

Originally posted by Jon Dornback:
thought you might be interested to know that there is a java jabber library being developed. it doesn't look complete, but maybe some ranchers out there can lend a hand to help write the library.

Cool. Hopefully we will see some more development in client libraries.
-iain

RMI is great if you can guarantee Java at both ends of the conversation. You can use RMI-IIOP to talk with RMI on one end to CORBA at the other end but that introduces some complexity.
One serious down side with RMI is talking over firewalls. This is something RMI doesn't handle very well at all. Although there are producuts like RMI Proxy (www.rmiproxy.com) that allow you to proxy RMI through a firewall.
Another is security. RMI is really designed for lan connections over a semi-trusted network. Denial of service attacks for example are really effective against RMI. You can use code signing to protect RMI to some degree but there are many aspects of the technology that simply aren't ready for direct Internet exposure.
RMI over a VPN though pretty much solves these problems if you can establish a trusted VPN between communicating parties.
Jini (Java distributed computing framework see www.jini.org) ran into these problems because it was based on RMI communication. The Jini team at Sun is working on the next generation Jini system which includes a competely reworked RMI sub-system with all these issues being addressed (security, proxying, etc). Since the Jini team is composed of most of the members of the original RMI team (and the original RMI team composed of many of the original CORBA team), there is a good chance that this next generation RMI being developed for Jini will eventually work its way back into the standard Java libraries (or at least be a new rmi like nio is the new (nonblocking) io library).
if you want to take a sneak peak at this new RMI, check out the overture project at www.jini.org. overture is the early access codebase for Davis (that next generation Jini release).
-iain

Cool. I'd be interested in hearing what the outcome of that conversation is. There are many small 3rd party vendors stepping in to plug these security holes in proprietary products so it may be worthwhile to check them out. Even the big players like AOL are starting to offer enterprise services with more secure IM. New players like Sprint are also getting into offering enterprise IM services with a variety of security options. I prefer open technologies but I also like to buy a solution rather than build it myself. laziness rules.
-iain

Hi,
Thanks for the kind words and great comments.
My book develops a client library focused on testing the Java Jabber server developed throughout the book. I agree that there is a strong need for a Java Jabber library that is clean, small, and focused. Due to the intent of the book's client code (server testing) it doesn't meet these requirements.
As you point out the JabberBeans code tries to do a lot and has not seen much active development these days. My book's client code is nice in that the code is small and simple so is easier to understand. However, it is code developed for teaching/reading so it leaves out the normal error checking and handling that you'd want in production code.
Honestly, I think a fresh start would be best. If you were to start an open source project (like on sourceforge) I think you'd have quite a few people that would help. In my opinion, rather than using SAX parsing as is done in my book, I think JDOM is the way to go for a client library.
In addition, a basic framework for Jabber packet handling with plug-ins for each protocol would make the library easier to use and configure for any particular problem. My book code uses this basic design and could serve as a model for doing this. However, I'd probably use a standard plug-in standard like Java Servlets rather than my book's ad hoc method (the book code tries to avoid too many external library dependencies so there's quite a few areas where it can be improved simply by using the logical standard technology rather than my simpler, and less capable custom code).
Whew. So if you're still with me, I agree with you. We need such a library and it doesn't really exist today. Hopefully someone will seize the opportunity!
-iain

Hi,
Jabber is designed to move as much IM related work as possible to the server. this makes client development easier and allows you to handle a lot of these issues on the server. The protocol remains efficient enough that even with all this server-side work, Jabber servers on standard x86 boxes can basically saturate their network connections long before they max out their CPUs. (Basic IM is primarily a network bound domain no matter how much work you push to the server).
Jabber itself uses a distributed client-server architecture (see the topic on IM in Java). This archicture is the same as is used in email. Messages go from a client to their server. From that server to the recipient's server, and from the recipient's server to the recipient's client. It is expected that direct server to server communication occurs however there is nothing in the protocols to stop servers from relaying messages through special Jabber router servers (something that larger IM providers will probably have to use).
The design allows you to break up the messaging space into smaller domains, each controlled by a central authority. However there is no overall authority for the Jabber network as a whole. The design makes gatewaying into other systems simple.
Most Jabber servers (including the open source reference server jabberd) includes "transports" that bridge from Jabber into other IM systems. A typical jabber identifier may look like:
iain@shigeoka.com
Which means send a message to "iain" at the Jabber domain "shigeoka.com". Most transports use a simple naming convention to rewrite IDs intended for foreign systems:
iain@aim.shigeoka.com
for example may indicate to the server that you want to send a message to screen name "iain" in the "AIM" transport located at "shigeoka.com". Jabber clients don't see any difference between a native and non-native IM message or user (although smart clients can query the server for gateway information, and may indicate foreign IM users with special icons).
If the protocols for the foreign IM system are well document and open, Jabber can and does provide excellent interoperability. IRC for example is very well supported.
Interop problems emerge when trying to access proprietary networks. Some tolerate reverse engineering (like yahoo) and others actively fight Jabber transports (like AIM).
For a while, I was seeing new Jabber transports coming out almost daily to adjust to AOL changes to AIM specifically targetted at blocking Jabber servers. Things have settled down now with AOL mostly doing server blacklisting on anyone bridging too many users into AIM, and most Jabber developers recognizing AOLs desire not to be accessed.
-iain