Eddie Sheffield

I just got hit with a project that seems like it could use web services. Basically a survey tool that can operate standalone (a Java app) and can sync back to a web server to send survey responses and download more questions. Initially only Windows clients are required, but the ability to expand to others like PDAs would be a nice plus.

Problem is, other than working through a few examples a while back I'm pretty new to web services. And of course I have to have some kind of rough architectural proposal together by COB tomorrow (4/22). I'm looking at a Java client, web based admin, servlets, and a backend DB. Not planning to use EJBs for this. I have a couple of questions right now though if anyone can help.

1) Security - I assume using HTTP as the transport I can use SSL - correct? I'm going to look into WS-Security too, but so far it looks like it's mainly for authentication, and there aren't many (any?) complete implementations available. I think for my rather simple needs I can "roll my own" for authentication if need be. Any other suggestions?

2) Libraries - My first thought was JWSDP, but does it (at least 1.5) only work in certain containers? That's the impression I get from Sun's pages about it. They point you to a special version of Tomcat and two of their commercial offerings. What is there to JWSDP other than a collection of libraries and a few tools that would make it container specific? I'm also looking at Axis - should it work with any container?

Thanks for any and all comments!

Eddie

HttpSession is strictly web side. PipelineSession can span the web server / EJB server gap and is usually used for storing and tracking session attributes between InputProcessors / JSPs / Servlets and PipelineComponents.

Passed yesterday (8/26/03) with 55/59. Didn't really study a whole lot to be honest, just tried to hit areas I haven't used a lot in the Deshmukh book. Been messing with servlets on and off since they first came out, and JSPs for a bit over a year. Only sections I missed on were custom tags and sessions. I've done some custom tags, but not enough to have all the details memorized. And most of the session mgmt I've dealt with has been in BEA Portal using the custom session handling in there (Pipeline sessions).

I think you're out of luck. You can't even run console (text only) Java apps on plain MS-DOS. And since Swing is at it's lowest level built on AWT (at least for the enclosing window/frame) and AWT just peers to the OS's windowing system, it sure isn't going to work.
A quick Google search did turn up this effort: Taurus JavaVMProject They are developing clean room JVMs for various OSs and devices, including MSDOS. But the MSDOS effort doesn't appear to be very far along at this point. AWT is not implemented yet, so that wouldn't help you much.
[ August 21, 2003: Message edited by: Eddie Sheffield ]

Originally posted by Jen Yang:
I'd really like to use a HTML table. But the table has to have scroll bars at both directions. IT has to look exactly like a Swing table.

If you can otherwise get close enough to the look you require with an HTML table, you might be able to use an IFRAME to contain a page consisting of only the table. That should allow you to get the scroll bars you want. But if you REALLY have to use a JTable, then an applet is the only way to go.
Either way (IFRAME or applet) you're going to have to watch out for browser compatability problems, so make sure you consider what browser(s) your intended audience may be using.
HTH!

You've hit on my biggest pet peeve with RMI - lack of location transparency. I haven't found a solution that I would consider elegant. What I've done in the past is declare an interface that is identical to my remote interface EXCEPT for the RemoteException declarations. The actual business object implements this interface. In local usage, the client accesses the BOs directly through this interface. In remote usage the client uses a proxy that implements this interface and wraps the actual remote proxy, catching RemoteExceptions and wrapping them as either application specific exceptions or RuntimeExceptions as appropriate and rethrowing them. The proxy might also implement some kind of retry logic. I usually use some kind of factory in the client that vends the correct type of proxies as required.
This approach has worked for me, but I don't really like it. You end up with the duplicate interface declarations that need to be kept in sync and it just generally messy. Another option would be to consider an alternative like the Apache Jakarta AltRMI project (http://incubator.apache.org/projects/altrmi/)which is designed to be an RMI replacement with better transparency. I haven't used it, but it looks promising.
HTH!
Eddie

Originally posted by Bill Skrypnyk:
I can't see much of a difference in the specifications.

Not a lot of difference, except the later spec makes no mention of the SingleThreadModel. The info from the book only makes sense in light of the earlier spec with the SingleThreadModel info.

I think the ambiguity comes in around the 'pool of instances' wording. Having the same servlet deployed under different names and having one instance per declaration is not the same as having a pool of instances of **thread-unsafe** servlets.

Very true! They are two distinct concepts. You can have multiple deployments of either thread-safe or thread-unsafe (SingleThreadModel) servlets under different names in the same web app.

Thread-unsafe I read as NOT implementing the SingleThreadModel.

That's backwards. If you DON'T implement SingleThreadModel, you're telling the container that the servlet IS thread-safe, and therefore (by the spec) the container must service concurrent requests to the specific servlet deployment via multiple threads running over the SAME instance of the servlet. If the same servlet class is deployed several times under different names, there is a 1-to-1 correspondence of deployment to instance.
If you DO implement SingleThreadModel, the implication is that the servlet is NOT thread safe and each concurrent request must be serviced by a separate servlet instance. These instances may be pooled by the container. In this case there would be a 1-to-1 correspondence of deployment to pool. If pooling is not used, then the requests would be serialized to a single instance.
Eddie

No, the book is correct. That statement in the book is about a servlet implementing the SingleThreadModel. But note that the current SCWCD exam is based on Servlet 2.3 and JSP 1.2 specs. You're looking at Servlet 2.4 spec, and one of the differences is that the SingleThreadModel for servlets is deprecated. So looking at the same section in the Servlet 2.3 spec:

SRV.2.2 Number of Instances
For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration. However, for a servlet implementing the SingleThreadModel interface, the servlet container may instantiate multiple instances to handle a heavy request load and serialize requests to a particular instance.
In the case where a servlet was deployed as part of an application marked in the deployment descriptor as distributable, a container may have only one instance per servlet declaration per virtual machine (VM). However, if the servlet in a distributable application implements the SingleThreadModel interface, the container may instantiate multiple instances of that servlet in each VM of the container.

Also, under either 2.3 or 2.4, it is perfectly acceptable to have the same servlet class deployed multiple times under different names by specifying multiple servlet entries in the deployment descriptor. This is useful if, for example, you resuse the same servlet in different places and with different initialization parms. In this case there will be multiple instances of the class instantiated, but only once per declaration. That's assuming the servlet is NOT a SingleThreadModel servlet - if it is then pooling may be used as described.
So until Sun updates the exam to 2.4 (and I haven't heard of that happening anytime soon) stick to the Servlet 2.3 spec for study purposes.
HTH!
Eddie

Couple of things to add. The classpath would probably be OK *IF* you get rid of the incorrectly nested quotes. The path for the QTJava.zip lib file is surrounded by quotes in the CLASSPATH= declaration, but then the whole classpath is again surrounded by quotes in the actual program execution line. Eliminate one set or the other and it will probably be OK.
Another thing that I've done with similar problems is to use the "8.3" form of directories that have spaces. For example,
C:\Program Files\Java\j2re1.4.1_01\lib\ext\QTJava.zip
becomes (probably)
C:\Progra~1\Java\j2re1.4.1_01\lib\ext\QTJava.zip
You can use dir /x to see a directory listing with both long names and 8.3 names so you can find out the exact name to use.
HTH!

If my understanding is correct, I have to admit I can't quite think of a real situation where you would need to do this. What kind of client are you replying to? If it's standard web browser then you should never be sending more than one kind of data in a response at a time. For example loading a web page containing an image and a jar file (applet) the browser will send 3 separate requests - one for the enclosing HTML, one for the image, and one for the JAR. Assuming your servlet is configured to handle all these access, then it will have to examine the request to see what is being requested, set the content type and return the appropriate data.
On the other hand if you are actually communicating with some kind of client that can handle receiving multiple types in a single stream (something like a MIME message perhaps) then it will probably have it's own specific protocol you'll have to follow anyway. For such a beast I would expect it might use some kind of custom content type setting and would have it's own way of identifying the different parts of the data stream.
I may well be misunderstanding something here though, so don't hesitate to say so!

I've got you beat. I *just* got the results from my SCJD for Java 2 and I originally registered in 1998 (or maybe 1999)! I have the odd combination of SCJP 1.1 and SCJD 2 - trying to find out if I can go for SCWCD and some of the others without taking a newer SCJP test. Did basically the same thing though - off to a great start, then job, layoffs, etc. got in the way. But I finally did it, and you can too!
Good luck!

I finally got my results! Took something like 8 weeks. After six weeks I contacted them and it turned out when I registered for the written I ended up with a new ID, so my app and my written were never associated together in their system.
Anyway the breakdown was like this:
General Considerations: Maximum=58 Deductions=5 Actual=53
Documentation: Maximum=20 Deductions=0 Actual=20
GUI: Maximum=24 Deductions=0 Actual=24
Server: Maximum=53 Deductions=0 Actual=53
Total: Maximum=155 Deductions=5 Certification Score=150
I have to admit that I finally had to quit reading the SCJD forum here - I kept seeing things there that made me think I needed to change my code. Finally decided I had to quit reading or I'd never have it finished.
I probably took longer to complete this than anyone else ever! I originally registered right after I passed SCJP 1.1 in 1998! But I got caught up in job changes, the "dot-bomb", etc. and only recently managed to get back to it. Glad it didn't expire!
Probably going for SCWCD next - it's most applicable to my current work.

I just happened to look at the Motorola site yesterday. Actually it appears that "proving" you're a developer is paying $500 for technical support, plus a fee to have your phone upgraded and you have to send it to them to do it.
Check it out: Convert your T720/T720i to a Developer Phone
For downloading MIDlets, I think that in addition to needing a server to download from, it needs to have the appropriate mime types registered for the JAR and JAD files.

Well, it's been 6 weeks today since I took the written and about 7 weeks since I uploaded my assignment and still nothing. All I see is on the Prometric site where I took the written. I'm starting to wonder if my upload didn't really work, even though it seemed to from my end. Who can I contact to check on this?
Thanks!

I'm having a wierd problem in Netbeans on Windows XP, JDK 1.3.1_08. Apparently new .java files I create are being saved using the Unix convention for line separation (\n) and new .jsp files are using the Mac convention (\r). The Unix thing doesn't seem to cause any problems, but when I try to deploy the JSPs on Weblogic 6.1, they won't compile. If I load the files into JEdit and resave them after setting the separator to MS-DOS convention (\n\r) then everything is fine.
Any ideas? Can you specify the separator to use? I've searched google and the netbeans sites, but haven't seen anything like this mentioned.
Thanks!