Not to show how terribly behind the times I am, but isn't that precisely one of the things Axis does?
To be perfectly honest, I don't know. I don't know much about Axis, so I'm not sure I can comment. But, being as how not really knowing what I'm talking about has never stopped me before... :)
You pop a war file into your container, add your existing business code, and voila, standard java methods are exposed as web services?
From my reading up on Axis, which amounts to a FAQ and an introductory article, I'm not sure that's really all there is to it. However, it doesn't seem like the difference between the amount of work required for Axis and for my solution are much different. So, I don't think I can argue amount of work in my favor.
With Axis though, you are really counting on the fact that you have real business classes to expose, and as my discussion with Leon here has touched on that, I don't think that's something you can assume is always true. Not all applications are engineered "properly", sad as that may be :)
More importantly though, where I think it differs in a material way, is the fact that my solution gives you the ability to expose services but still use all the resources of your container, your application and Struts. For instance, if you have to create a new webapp with Axis and then put your classes to expose into it, you also will need to set up whatever resources those classes may need, your JNDI database entries and such. They already exist for your Struts app, so why go through that extra effort?
Also, what if you have some classes that maybe have static configuration information specific to your application? You can bring them into the Axis app just fine, but now you have two places to maintain things like that. Someone might argue that you shouldn't do things like this in the first place, and I'd be inclined to agree, but that hasn't stopped people from doing it in the past :)
Most importantly though is that you can still use what Struts gives you, things like form validation and internationalization, plus some degree of the control layer, depending on how your app is designed. I think with Axis, you would have to either write some code to duplicate these things, or have duplicate code in two apps.
Another difference, if I'm understanding the article I'm reading correctly, is that with Axis you can't expose a service that spans multiple objects. You must define whatever methods you want to provide through your Web service in a single interface or class. With my project, assume you have an Action that makes use of three different business delegates to fulfill some request, maybe a list of accounts for a given user, with balances for each, and details about the holdings of each account let's say. I'm not sure you could pull that off with Axis in a single service request without some refactoring of your code. On the other hand, with my solution, you could expose that Action as the service, no code changes, very quick and easy.
In any case, as I've said a couple of times before, no one should look at this project and think "ok, that's how I should do Web Services". Not at all. I would dare say that in many cases, perhaps even most, this approach is not what people should do. It's just another tool in the toolbox, one that may be appropriate in some cases.
Not saying your plans won't cure cancer, but are you reinventing the wheel?
I wish I was curing cancer! :) I don't think I'm reinventing the wheel, but I wouldn't argue that I might be inventing a slightly different kind of wheel. That's probably fair.
w
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
On Sat, 22 Jan 2005 18:24:10 -0500 "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
Leon Rosenberg wrote:
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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
