I spent the last couple of days designing a web service API.  Last time I did that was more than six months ago, so I forgot a lot of little tricks and gotchas which I had to relearn.  To save you some trouble, here are some notes:

Getting Started

Currently, Visual Studio .NET is the best environment to start in for web service design.  So I started a Web Service project in VS.NET 2003, wrote my API classes in C#, and launched the service to get WSDL.  I also wrote a .NET client to polish the API.  BTW, VS.NET generates doc/lit style web service which is usually what you want.

I used only simple datatypes to avoid interop issues later.  Complex datatypes should be used only if the benefits are clear because most binding generators will map them to classes which have to be instantiated on both side.

You might want to go easy on the Enums too because VS.NET uses enum symbol names as string literals.  I dislike verbose XML, so I used simple character flags (similar to fopen mode flags) instead as a compromise between fully descriptive strings and bit flags although I used strings to represent the flags for extensibility.

Interop by Passage

Now that I had a WSDL, I fed it to Apache Axis's WSDL2Java tool to generate Java bindings.  I ran into several interop issues with Axis 1.1 so I ended up using Axis 1.2beta2 after a few hours of agony.  Since the service I was designing will be implemented in Java, I generated server-side bindings first and hosted them in Tomcat.

Once the Axis-based service was running, I added a Web Reference to it in my C# client and made sure results from the Axis-based service matched the .NET-based service.  Note that at this point, you have two WSDL, one from each side.  You'll eventually have to let one of them go depending on where the service will be hosted in a Java web server or ASP.NET, but it's nice to have both for developing clients in other languages.

At this point, it's smooth sailing as far as interop is concerned.

Version 3.0 of Sysdeo Eclipse Tomcat Launcher plugin was released today.  According to the readme file (txt), source code debugging should now work again although existing Tomcat projects will have to be tweaked by hand:

When using Tomcat 5, Eclipse does not stop on breakpoints set in generated java files for JSP. This is fixed only for new Tomcat projects, for existing ones follow those steps:

...

My version of the instruction:

1. Open your Tomcat project's 'Properties' dialog.
2. Goto 'Java Build Path' >> 'Source' panel.
3. Make sure 'Allow output folders for source folders' checkbox is checked.
4. Select and expand Tomcat 'work' directory in the list of source folders above the checkbox.  If you don't have it, add it.
5. Select the last child item (should be 'Output folder: blah') and click-on the 'Edit...' button on the right.
6. Set or browse to the 'work' directory.
7. OK, all the way back.

The problem was that, while the 'work' directory was known as a source folder, there was only one output folder (usually 'bin' or 'WEB-INF/classes').  Since Java files generated from JSP files are compiled in-place by Tomcat, object files (.class) ended up in the 'work' directory instead of the default output directory where Eclipse debugger was expecting them.  So the fix was to tell Eclipse that .class files for the Java files in the 'work' directory are within the same directory.  Duh.

Thanks to Bruno Leroux for writing Sysdeo Tomcat plugin.  Hey, Bruno.  Where is your tip jar?

Sorry about the lack of posts lately.  It wasn't that I was busy.  There just wasn't anything to post about.  Having my wife and son revolving and evolving around me again put my mind off my blog also.  It's amazing how fast the days go by when I am not posting.

Some soundbites rom The weakest security link?  It's you, a recent News.com article:

People are the weakest link.

Education is the first line of defense.

People are still not thinking before opening an (e-mail) attachment.

The big problem with educating employees on security issues is being able to track whether you're getting through to people.

Everyone knows about viruses, for example, but half the people don't have antivirus software.

While I agree that people are the weakest security link and even the world's strongest lock is useless if not used, I don't think that training employees about security and tracking security policy compliance is enough to fix the problem.

What's the missing ingredient?

Helping users protect themselves.

Just as training drivers all about driving hazards is useless if the driver is a blind, users can't protect themselves if they are not fully aware of what is going on around them.  Was there any suspicoius activities involving my account since last time I signed-in?  Is there someone accessing my online bank account at the same time I am?

If a hacker broke into your computer remotely and used it to send phishing e-mails or spams, how would you know?  Unexpected blinking network connection lights?  Something is wrong when it's easier to keep track of friends logging into their computers than strangers logging into our computers.

Unfortunately, most designers of today's security products see the user only as an input device: I'll give you access to these if you give me this and that.  This mindset encourages people to be more concerned about lossing access than gaining protection.  This is why people reuse passwords and write them down in easy to find places.

Security companies need to start thinking more about helping users protect themselves by providing more information about what is going on and letting them play an active role in security.  If something suspicious is going on, don't let the information sit until probability crosses some security policy thresholds.  Inform the user rightaway.  Remember that, to the user, no news is good news so they'll think what they are doing is all right unless they are warned away from dangerous edges.

There are ways to inform the user without getting in their way too much or making them paranoid.  For example, if an e-mail message has executable or unknown file attachements, mark it visibly as potentionally dangerous.  Hyperlinks should always clearly present the destination URL to the user instead of hiding it behind a possibly bogus text.

Did you know you can write 'applets' in .NET?  If you have .NET Framework installed, look at your Internet Explorer's Internet zone security settings, specifically the .NET Framework-reliant components section.  Unless you changed your security settings, your IE is configured to silently download and run both code written in .NET.  It doesn't matter whether the code is signed with Authenticode or not.

A good example of .NET applets/controls -- note that Microsoft probably calls them something else (web controls?) -- is this VG.net demo.  VG.net is a pure .NET vector drawing library.  BTW, you'll need Windows, IE, and .NET Framework to see the demo.  Once you have seen the demo, View Source of the web page.  It has nothing but reference to a style sheet and an object tag.

The style sheet is just used to stretch the object tag to fill the page.  The object tag references a DLL, WebControls.dll, located at myxml.com website.  IE loads the 'applet', notes that it's a .NET library, checks IE security settings, and runs the DLLs inside a sandbox of sort for security sake.

A brief visit to the .NET Runtime Security Policy reveals that, for the Internet zone, .NET 'applets' can use File Open dialog, paint into the 'safe' top-level windows (probably means the window they instantiated in), print 'safely' (huh?), and are given 10K of domain-specific isolated storage as well as a private clipboard, size of which may or may not be counted toward that 10K.  I am not sure whether the isolated storage is persistent or not.

I am not too worried about the Internet zone security policy, but the security policy for LocalIntranet zone does raises some concerns.  For example, there is no UI restrictions at all and isolated storage size limit is set to some huge number.  Note that I haven't figured out the specific implications of these settings yet and I doubt Microsoft engineers haven't vetted the sanity of the default security settings.  So I think it's early to sound any alarm.  But I am intrigued and disturbed.

On Sunday, my wife and son returned from Korea.  They also brought a mountain of luggage, two full carts worth.  Since my wife and I already had more than a decade of arguments over her seemingly unbreakable habit of moving mountains across oceans, all I could do was sigh and hug.

My wife and I are on the extreme opposites when it comes to luggage.  I despise luggage so I travel very light.  For a month long trip to Europe, I would take two underwears, two pairs of socks, two T-shirts, one jean, one slack, one jacket, and a pair of running shoes.  Since I am going to be wearing one set of everything plus the jacket and the shoes, the spares could fit comfortably into a small carry-on.  If the jacket has big pockets, I could travel without any bags but I use the carry-on to avoid getting grilled by immigration officers.  And on my trips, I rarely buy anything I have to carry.  If it's something big, I ship it. 

My wife, on the other hand, carries everything.  Her annual trips to Korea usually starts with increasing shopping activities a month or two before the trip.  In buying her gifts, she ignores logic completely.  I have seen her buying goods made in Korea as gifts to take back to Korea.  On this trip, she brought back goods she bought at Costco in Korea, goods made right here in California.  She said they were on sale over there and saving a few bucks on pots and pans made perfect sense to her.  Oy.

And much of the luggage was food.  For example, she brought back two boxes of ramyeon, dry noodle in a cup.  Of course, our local Korean markets sell them by boxes too but my wife said these are fresher.  Fresh instant noodle?  Arghhhh!

When I was growing up in Korea, I frequently saw a Korean women carrying heavy stuff while her husband walked ahead with hands behind his back.  Until I got married I didn't understand why Korean husbands weren't helping their wives.  Why?  It's because they already had their decade of fruitless arguments and all of them reached the same compromise.  As for me, I help out despite my frustrations but also try to avoid travelling with her to Korea.

Between Mars and Venus lies an impenetrable astroid field of luggage.

Wired reports on Electonic Arts' decision to shut down UXO (Ultima X: Odyssey) and goes on to elaborate on the pain and cost of running a massive online games.  While developing the game client and server itself is within the realm of developers' abilities, creating the content of a virtual world and keeping it an interesting place to live in is a difficult and neverending task that most developers will find difficult to manage, even if they have a deep pocket like EA.

The missing ingredient in today's online games that full 3D online world developers forgot to translate from MUD (Multiple User Dungeon, a text-only online world) is community participation in building and maintaining the online world.  Instead of hiring legions of artists and area designers, they should have leveraged the creative power of the players themselves by creating tools and offering incentives.  With such legions of superusers, all they needed was a much smaller staff to control the legion.

Player participation in running online worlds should not stop with content but also operation.  Let the superusers handle most of the in-game headaches such as user complaints and conflict moderation.  Going beyond that, superusers should also be used to play NPC roles such as monsters, shop owners, etc.

Unfortunately, EA looked only at the numbers and chose the easy way out instead of using UXO as an opportunity to explore more creative options.

For some reason, Firefox address bar stopped working today.  It simply stopped updating and also won't accept new URLs entered into it.  Only changes I made to the system today were latest set of Microsoft security patches and Sage, a Firefox extension which Tim Bray recently mentioned.

I uninstalled Sage but the problem persisted.  So I proceeded to uninstall all the extensions and restarted.  Still dead.  So I uninstalled Firefox 0.9.1 completely and went to the Mozilla website.  Woo.  Firefox 0.9.2 was out.  So I installed it only to find the problem still there.  Hmm.  Could it be that those five Microsoft security patches I installed today somehow disabled Firefox address bar?  I doubt it because Mozilla 1.6's address bar still works.  Has Sage got too clever and messed up some Firefox settings and failed to restore it during uninstall?

I don't have the answers yet because I don't have time to dick around just so I can point a finger at Microsoft.  I am sure there will be an uproar in no time if it is true so I am going to wait and listen.  Meanwhile, I am back on IE.

Update:

After posting, I realized that Mozilla application data was still in the Documents and Settings directory.  Wiping that out fixed the address bar.  So it looks like the problem was Sage.  That's the trouble with being extension happy.