Sunday, April 28, 2002

Web Services (not!) Web Services was a really bad name. That's the category most people see XML based data exchange falling into because that's where most of the public exposure has been. I might be myopic, but the REST argument seems to be trying to force things into a second generation CGI type approach, which is a fine solution for many things. REST seems useful for simple, public APIs (with a relatively small number of parameters). UserLand (as a good recent example) seems to be poised to transition to a REST based update API, which makes a lot of sense. If done in the way I see them going, they'll get a better idea of who is running what and users will have a bit less confusion about their update status. This is not where I see SOAP going. At JavaOne, I asked a lot of vendors what their customers were doing with their application servers. The top answer seemed to be creating connections (or a transition layer) between various legacy systems (often with the idea of making these new connections available to others -- not necessarily public). My current usage is similar, as I am working to build a bridge that deals with a couple of backend systems and several middleware layers. The result we're looking for is one API for provisioning. Once you start heading down the road of creating a single API, you also need to consider making it widely available. If you are committed to Java everywhere, an EJB or Servlet API is about as far as you need go. If you seek a little more flexibility, XML-RPC might serve. SOAP is another option which seems to define four (additional) important concepts... An envelope, with an area for optional data and a very reasonable error handling specification. More concrete types than with XML-RPC, with considerable room for extension. Structure definitions (in a fashion similar to C) are supported (XML-RPC supports arrays, but does not seem to support type aggregation into user defined complex types) along with serialization of custom types (which can negatively impact interop if used). Named parameters, which allows strongly typed languages to interoperate with more loosely typed languages using named parameters without enforcing a parameter order requirement. Multiple protocols. This is the really big win, long term. Todays SOAP only does HTTP and SMTP, but I see that the seeds for additional protocols are there. Adding an scp (or sftp or whatever) based protocol option to Axis (as an example) seems pretty straight forward. So, why SOAP? We might first ask, why XML (getting back to SOAP later)? The data in our system is pretty complex under some circumstances. XML documents allow us to define a textual representation of these data structures, so long as we have the ability to use complex XML. XML also allows loose API coupling, with default parameters if needed. If done properly, we can make significant changes on either side of the API, without having to make coordinated system changes (new input parameters which are unknown should be ignored, new parameters which are not provided should have reasonable default values). This leads to operational flexibility (systems can be upgraded independent of one another). If adopting XML as a document (or message) format, you are left with XML-RPC, SOAP or some sort of homegrown monster. XML-RPC did not meet our needs for standardization (although it's getting closer there as more implementations arrive) or data flexibility (there is a very constrained data set). Although our security concerns are not yet met via by SOAP (or any other XML interchange format) we can utilize secure internal connections because we're using TCP protocols (not ideal, but it works for now). There are SOAP implementations which are known to work in all of the backend environments we need to connect with and sufficient experience to connect any needed middleware layers (via SOAP). So SOAP it is. I am still open to using XML-RPC, but I don't see a real upside. If you do, or think I am full of it for any reason, I would love feedback (which I will post here). 11:39:05 PM

Family ztuff Me thinks I am going to need categories, having avoided them until now. I want to continue to inject personal information into the more normal technology ramblings and stupid ztuff. Hmm... We spent a bunch of time today outside doing yardwork as a family, and as usual, it was a lot of fun. Mostly it was just clearing debris, but we also worked on doing some temporary repairs to a section of our fence. It's pretty obvious after today that we need spend some real money and replace all the wood there, but that'll have to wait until next month. For now, the big hurt areas are back together and we can develop a real plan (and fit that into the budget). We also laid the ground work to get rid of the weeds and hung some of the new plants that Sarah bought. Jonathan took over on digging out the weeds from big plant holders and also helped with all the little jobs running tools from here to there. He's just too funny sometimes, so eager to help, but frustrated because he's not big enough for the job at hand. The mostly dead tree from late December is now fully dead so we're going to have to do some serious digging. That corner of the yard is starting to look a little bare, so I think we're going to have to plant a new tree over there, but in the meantime the view of the canyon is terrific. From here on out, Adam is in charge of wood related projects. I asked him today to be in charge of the deck replacement we need to do as soon as he has plans ready to go. He's charged up about it and I no longer have to worry about it, which is good because I don't really know what I'm doing. When we start, he's the foreman. Grunting and sweating in the lovely Southern California springtime... what could be better? 7:53:12 PM

Python accolades continue to roll in... Stuff like this from Dan Shafer, combined with Kevin Altis' weblog, the ongoing evangelism of Mark Pilgrim and recent rants by Bill Bumgarner are beginning to make me feel a bit stupid for not knowing more about Python. As if I don't already have enough problems. I first learned about Python in '99 or so, but last year it came home to roost when a co-worker was extolling the virtues of Zope. It looked darned interesting, but I just didn't have the time. He ended up re-doing a fairly major site in his spare time using it. I tried to keep up, but faded. I've done a conventional install using download binaries and am going to try doing it via Fink (on my PowerBook) as outlined in this bbum rant. Now I just need to plan some time to learn this thing. Thus far, 2005 is looking pretty open... 7:09:53 PM

Designer personas Meg Hourihan has written a very good article which describes her experience creating and applying user interface use cases (aka personas) for in house testing. Apparently she learned this from something Alan Cooper wrote (The Inmates Are Running the Asylum), which means I need to re-evaluate Cooper. It's been a long time, but I believe it was he who fended off the notion of cognitive (or spatial) familiarity, which had led Mac applications to put the most likely dialog option on the bottom right with the opposite choice next to it and completely optional ideas over on the left side. The idea is that Roman language readers (reading left to right) read to the end and find themselves at a reasonable default. Should they disagree, they back up a little bit and find a way cancel the whole thing. Wanting more options, they scan back over to the optional items on the left side. For languages which read right to left, or top to bottom, placement of buttons needs to be rethought based on the target audience. But I digress (as usual) ... User Interface identities (use cases, personas, whatever) are important in the architecture and user interaction design of user targeted applications. In our little group four years ago we were talking about Ma, Pa and Junior Kettle. Our mistake was in never fully fleshing out Ma and Pa, although we had a good general idea of who they were. We also had Junior stereotyped; he was our example of the demon spawn, out to wreak havoc in a multiuser environment where he knew more than Ma and Pa. A larger cast with more evolved attributes would have helped to make our software better. Meg is definitely on the right track here. For anyone designing user interfaces today, these ideas need to be parmount. For some further reading, here is a very good Cooper interview in two parts (one and two) with a rebuttal by Jef Raskin. 6:32:31 PM

© Copyright 2002 Dave Ely.