axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J. Hondius" <>
Subject Re: Webservice designing considerations
Date Mon, 18 May 2009 08:49:03 GMT

We are doing something like that.
 > The complete backend
 > Multiple frontends

Not 100 classes yet, but we will end up with that number.
Our approach was to start small, and develop tools en a 'worksystem' 
from there.

We chose to use Axis (in the form of WSO2's WSAS for ease of use)
and POJO's, no bells and whistles, to keep it as free as possible from 
any dependencies.

The POJO's are developed as regular libreries.
They can be used for other goals like a destop program.
They also contain special methods that are to be used for 'publishing' 
as a webservice.
In the services.xml inside the jar/aar where the pojo's are, only the 
public's are exposed.

We describe the 'to be published' methods first, and work from there.
I'm sure that this could be done with a UML modeling tool too.
Some tools (modelmaker?) generate code from the UML.

Designing 100's of classes first would not be my approach though.
We learned a LOT from the first 3 classes that i could never have 
thought of beforehand.

POJO's do have drawbacks, but independency and reusability were major 
design issues.
Axis and the POJO's performance was better then expected BTW.

Just 2c

Tom Mayer schreef:
> Hi List,
> I'm at moment in the stage of thinking about how to design a completely
> new (in the meaning of no codebase available) webservice...
> And I'm really confused now about the best approach. Already took a look
> at gsoap, axis2, cxf and few others.
> Tutorials are only for webservices with one or two operations. When
> completed my service needs few hundred operations. It will be a kind of
> customer management application. The webservice should be the complete
> backend, not any sort of data export.
> There should be one or two frontends implemented for web and windows
> completely without business logic. All business logic "exposed" through
> webservice.
> Ok, this application will be reflected in some UML diagrams containing
> about 100 classes. What do you think is the best (in the meaning of
> efficient and maintainable) way to write such kind of webservice?
> I already tried the way of constructing a webservice with WSDL first
> from eclipse WPT. I ended up with one service-skeleton class containing
> all web methods and really infinite class names
> (com.organisation.project.myclass) (ok there is my package in it, but is
> it indispensable to have this complete descriptor before all classnames
> in the service implementation?)
> Unimaginable to implement all my business logic in this one file.
> Is it a better approach to have your application smoothly running with
> all it's classes and then constructing the webservice like a wrapper,
> which acts like a application invoking the necessary functions from the
> complete constructed classes?
> I'm dreaming of drawing my UML class diagrams, annotate the specific
> methods of every class that should be exposed in the webservice and
> getting a nice structured (operation names like classname_functionname)
> webservice.
> Seems like I didn't got the "service oriented" vs. "object oriented" yet.
> Thanks for any suggestsions.
> Tom

View raw message