|
Hi again Tony...
I can see this thread evolved since
yesterday...fine discussion :-)
<Tony>
In this particular aspect, I prefer to work from
Java. The way I see it, I'm developing some business functionality, that might
be usable in many ways, not just as a web service. In developing the business
function, without any web services infrastructure, it can be kept clean and
easily testable. Once the function is sorted, expose it as a web service, using
Java2WSDL, some WSDL clean-up, WSDL2Java, with server side generation. Then the
web services implementation template can hook up to the business functionality.
Apart from the clean separation of business functionality and web services
infrastructure, there are some small mods one can make to the WSDL and web
service class, without needing to alter the business class.
</Tony>
I did this for a J2EE project, where Business
Facades where implemented as stateless session beans. On the Web Tier I was
using Struts and as mediator between Web Tier and EJB Tier I was using "Business
Plugins" based on the Business Delegate Pattern. Those business plugins where
called from the Struts action.
Anyway... When it came to expose some of the
business services as web services, it was way too easy to add another "action
class" to call the Business Plugin.
It was the new "action class" that was exposed in
the WSDL. Or actually the opposite, because I started to create the WSDL and
generated the new "action class" from there.
The current infrastructure (eg. software
architecture) was kept, just adding another "way" to the Business Plugins on the
Web Tier.
Regards
Henrik
----- Original Message -----
Sent: Tuesday, November 16, 2004 6:12
PM
Subject: Re: Best Practice
Thanks, Joe.
I've had a quick glance through the mailing
list, back a year, but couldn't find anything obvious, in the best practice
area.
In this particular aspect, I
prefer to work from Java. The way I see it, I'm developing some business
functionality, that might be usable in many ways, not just as a web service.
In developing the business function, without any web services infrastructure,
it can be kept clean and easily testable. Once the function is sorted, expose
it as a web service, using Java2WSDL, some WSDL clean-up, WSDL2Java, with
server side generation. Then the web services implementation template can hook
up to the business functionality. Apart from the clean separation of business
functionality and web services infrastructure, there are some small mods one
can make to the WSDL and web service class, without needing to alter the
business class.
Any more best practices
anyone?
Tony
Funny you should ask this
question.
When I asked it about 6 months ago it spawned a week long
thread that,
in my opinion never reached a conclusion. But, this is what I
gathered
from it. There are three schools of thought when it comes to
creating
Axis web services. 1) Start with a WSDL and generate your code
from
that. 2) Start with a class and generate a WSDL so that you can
generate
the WSDD. 3)Start with a JWS or message service that accepts a
string
and parse it with Castor or some other xml binding engine. Remember
each
one has it's own specific merits and drawbacks.
1) The WSDL
approach; you start with a WSDL and it is rather simple to
create. Plus,
it's the one location where you define your service. And
then everything
gets generated. The drawback comes in when you add
future functionality,
you end up regenerating things over and over
again. And if you've added
any functionality to any of the generated
classes outside of the impl
class, you have to be careful when doing
your generation, it will get over
written.
2) The class approach; you start with a class, I don't think
there is an
easier starting point for java developers. You create your
code and
expose it to the world using the WSDD's. The drawback of this is
generating the WSDD's. WSDD's are a little bit more complicated than
WSDL's. You could create them by hand, but it's more prone to error. And
to generate them you have to be pretty comfortable in ant, it can be
very hackish.
3) The String approach; I've never attempted using
this approach but
there is a relatively popular article that recommends
this. If you are
heavily invested into Castor or some other framework, I
see the merits
of implementing this approach. Also, you theoretically
could get by with
exposing only one service. The drawbacks of this, you're
adding another
layer to an increasingly complex puzzle. Axis does all of
the parsing
for you already, why add another layer?
I couldn't tell
you which technique is the most popular, I would say
that the WSDL and
Class approaches are the most common and are split
fairly evenly. The
people that I've have personally run into have used
the class approach
exclusively. But, some of them were exposing EJB's so
take that with a
grain of salt.
As for books/documentation, keep waiting for an Axis
specific book. None
exist show what you can really do with this
technology. Most just
explain the architecture. One thing I have noticed
though, version 1.2
documentation is way better than version
1.1.
For tools, Mindreef SoapScope, is an excellent testing tool. Reads
in
and validates WSDL's. You can also test the service by inputing data
into a form. I use this all the time. Cape Clear has a WSDL tool that
I've used a couple times. Very easy to create a WSDL from
scratch.
Axis is an excellent tool. It does have a lot of power in it
and can be
used in just about any way you wish. But, like EJB and other
distributed
technologies they need to be used where appropriate. Deciding
where it's
appropriate is something that comes with experience not reading
it from
somewhere.
Have a great day,
Joe
Plautz
|
