May I ask You what is the actual goal of your project?
"This project provides a simple mechanism whereby existing business logic components of a Struts-based application can be exposed as rudimentary Web Services without the need to change any existing application code."
Hmm, I don't understand the purpose of it.
The goal is pretty much what you quoted above... If you have an existing Struts-based application, and you want to expose portions of it as Web Services, this allows you to do it without changing any code, or introducing a new server element, or adding a bunch of extra dependencies.
I did originally have more grandiose plans, but that's what it boils down to now.
If you have an application with business logic components, they are well
defined by their interfaces.
You are getting into the same debate as when I first mentioned this some months ago. The point I made at the time is that many Struts applications are simply NOT designed properly... Many people don't do a good job of separating business components and dump a lot of stuff in Actions. Even when those components are separated out, sometimes dependencies are left on it being a web-based applications, or worse, being Struts-based.
We can argue that people shouldn't be making these mistakes, and I'd agree 100%. But the fact is that people have done this, are doing this, and likely will continue to do this.
The struts application on top provides some kind of view
on the business logic, it could be XML, CSV, HTML or anything. Whatever,
this view would be less well defined as the component itself, except for XML, which would already be a
WebService by the definition and therefore out of discussion.
I would understand it either way, building an automatic (struts/web)
application on top of a WebService, but this is something we already know as
XSLT. You in contrast are trying to build a well-defined interface on top of not
well-defined interface to access another well-defined interface. Why?
Again, your making the assumption that we're talking about a well-architected application. In those cases, my solution should probably not be looked at, there are better answers.
But, consider this situation... What if you have an application that has as one of it's functions the ability to display a list of accounts that a user has access to... Now, what if you want to expose this as a service? Let's say for the sake of argument that your application IS well-architected, so you have a business delegate that can perform that function, completely independent of the rest of the applications. Now, you want to expose this as a service quickly. How do you do it?
You could of course go get one of the many Web Service products that allow you to do this. But, you already have a server set up, the one running the application... you already have all the resources the app needs set up in the container... you already have a security mechanism built in... maybe you have encryption, and so on... why not use it?
Presumably, somewhere in your app you have a page that displays the list of accounts. You probably have an Action that you call to do this. All the security and whatnot is a layer above that Action. Why not use it all?
So, with my solution, you can, without changing any code at all (and that's a key point), expose that Action as a service. It's simple (within some constraints anyway). That's the kind of situation where my solution might make sense. It's certainly not the way Web Services should be done all the time, I don't claim that at all.
And again, if your application is really well-architected, you probably want to be looking elsewhere.
As for the project itself, i think you should consider reading ant manual
more carefully.
What you actually mean is I should read it AT ALL :) I've never read it. I hacked that ant build script based on some other I found. I personally use batch files to run all my builds, I only put the ant script in as a concession to someone that asked for it last time. I'm not a huge fan of ant in general to be honest.
Your project organisation is worth enhancement, i don't think WEB-INF is
something that should exist in the source-code, since it's one of servletcontainer
specifics and only needed in resulting war file for a webapp, but not for a
standalone application.
I'd have to look at the structure again, but as I recall, the whole thing is packaged as a sample webapp, and the source is included in that. For a long time I was in the habit of having a source folder under the webapp root, a habit I've since gotten out of (I now either put it under WEB-INF, or have it separate). I could move it, but I'm not sure how big a deal it really is, based on the idea that what your downloading when you get this project is in fact a webapp. I suppose you could argue that I should have a separate sample webapp and source package, and that might be a valid argument.
If you want i can help you reorganizing your project source and build file.
Go for it :) I have no objection if you have a better structure in mind. Unless I hate it for some reason, I'd be receptive to whatever you want to do.
And refering to files that are not included in the download package is at
least, aehm... irritating :-)
java -cp . WSClient Web Services Interface Test Client v1.0 Frank W. Zammetti -------------------------------------------------------------------
See testsrvc.bat for usage
Yeah, good point :) Just an oversight... that's actually a result of previously using batch files... now using the test.xml ant script to execute the test client instead of the old testsrvc.bat, but I didn't change the code to reflect that. Thanks for pointing it out, I'll add that to the to-do list :)
Regards Leon
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
