axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Davis <...@us.ibm.com>
Subject RE: [axis] User Roles and AXIS components
Date Fri, 16 Aug 2002 18:36:02 GMT





One of the advantages to having just a single jar file is that when a
server suddenly becomes a client (like someone makes a WS call from inside
a handler or service) then they don't need to worry about adding more jar
files.  One other thing to think about is when a client becomes a server
(like for a "local" binding) having a single jar file is nice there too.
I've never been comfortable with the idea of splitting the client and the
server since they're so much alike and share so much code.  I can see
splitting out some of the tools into an axis-tools.jar but like Tom said,
are they really taking up that much space?  You need to consider not just
how many jar files axis itself has but how many other jar files (logging,
mail, activation...) does it need too and does any benefit of that split
really outweigh the annoyance of yet more jar files to worry about.
(Not voting either way - but do have a preference for simple - which IMO is
one jar file)
-Dug


Tom Jordahl <tomj@macromedia.com> on 08/16/2002 02:22:30 PM

Please respond to axis-dev@xml.apache.org

To:    "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:    RE: [axis] User Roles and AXIS components




I have no problem letting go of axis for developers. :-)

I just want to make sure that the USERS of axis are thrown in to class path
hell by us suddenly shipping a handful of (additional!) jar files.

Lets break it down, we have:

 - client   (classes only for runtime access to a SOAP server)
 - server   (classes for supporting the deployment of web services,
             assumed to be a superset of client, must include Java2WSDL)
 - tools    (WSDL2Java, Ant tasks, tcpmon)

Lets look at what we gain by shipping different jar files for each of
these:

I would hazard a guess that many users would be interested in having a
client runtime to deploy with their applications.  So I am +1 to isolating
that out in to an axis-client.jar.  This should be defined as the minimum
stuff needed to fully support request/response processing to a service.

I am less convinced that an axis-server.jar would be of much use to many
folks.  Since class files aren't loaded unless used, the additional tens of
K saved by excluding the WSDL2Java classes and ant tasks isn't overhead a
server would need to save.

A separate tools jar might be useful, but I think a better proposal is to
create driver sh/bat scripts to run each of the tools.  This is much more
user friendly and gives a clear indication on where a developer might need
to start.

So in summary:
 - leave everything (including the ant tasks) in axis.jar
 - create a small subset of client-only runtime and create axis-client.jar
 - create driver scripts (which use axis.jar) for all of the tools we have
   (WSDL2Java, Java2WSDL, tcpmon)

Thoughts?

--
Tom Jordahl
Macromedia Server Development



-----Original Message-----
From: rsitze@us.ibm.com [mailto:rsitze@us.ibm.com]
Sent: Friday, August 16, 2002 1:38 PM
To: axis-dev@xml.apache.org
Cc: 'axis-dev@xml.apache.org'
Subject: RE: [axis] User Roles and AXIS components


axis.jar as is today.

In parallel, begin spinning out axis-core.jar, axis-dev.jar,
axis-tools.jar, etc...

You could go either way then.

Tom, one way or another the DEVELOPMENT community has got to let go of
axis and start shaping it for users...  and right now axis.jar is a closet
full of interesting gadgets useful to the development community, but not
so good in the real-world.  I'm OK with your stance, but only if you give
me room to grow.

I'll be on the chat when I get back from lunch.

<ras>

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development




Tom Jordahl <tomj@macromedia.com>
08/16/2002 11:53 AM
Please respond to axis-dev

        To:     "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
        cc:
        Subject:        RE: [axis] User Roles and AXIS components





+1 to keeping axis.jar the jar file that contains everything it does now.
-1 to removing anything from axis.jar

--
Tom Jordahl
Macromedia Server Development



-----Original Message-----
From: rsitze@us.ibm.com [mailto:rsitze@us.ibm.com]
Sent: Friday, August 16, 2002 11:24 AM
To: axis-dev@xml.apache.org
Subject: Re: [axis] User Roles and AXIS components


I was about to create an 'axis-dev.jar' file.  It crossed my mind that if,

instead, I renamed axis.jar to axis-core.jar, & put axis-developers
material in axis.jar with a META-INF/MANIFEST[Class-Path: axis-core.jar],
I might rock the boat a bit less... comments?  I myself have reservations,

but thought I'd toss this out.

Meanwhile, I'm moving forward with axis-dev.jar


*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development




"Steve Loughran" <steve_l@iseran.com>
08/07/2002 06:11 PM
Please respond to axis-dev

        To:     <axis-dev@xml.apache.org>
        cc:
        Subject:        Re: [axis] User Roles and AXIS components





----- Original Message -----
From: <rsitze@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Wednesday, August 07, 2002 3:45 PM
Subject: [axis] User Roles and AXIS components


> I think the time has come to reopen an issue regarding user roles and
AXIS
> component.  We have the following roles for which we are providing
> solution(s):
>
> 1.  AXIS developers - Develops and Tests AXIS code
> 2.  AXIS user-developer - Develops WebServices applications using AXIS
> core technology
> 3.  AXIS user-admin - Manages WebServices applications in production
> environments.
> 4.  AXIS end-users - WebService users who needn't be aware of AXIS at
all,
> other than stability, performance, etc.
> N. others? [feel free to enumerate if it contributes to conversation]

5. AXIS pointy-haired-bosses: these know nothing about axis but think Web
Services are cool and want one.

Maybe axis client and axis server should be split up

>
> However, I'm focusing more on the next TWO most important roles: (2) and
> (3).  These are our up-front customers, and these will make-or-break
AXIS
> in the end.  It is a fine balance between (2) and (3): (3) (based on
> understanding of (4)) is a the final decision maker/breaker in the end,
> but it will never get that far without (2).

agreed. production side (3) are always paranoid control freaks who
distrust
(2) and (4) in my experience.


>
> 1.  axis.jar : Core runtime components (standalone to satisfy (3)) -
> nothing in here should make a admin/security-guru uncomfortable.


maybe axis-core.jar; perhaps have a split between client and server with
different depenencies.

> 2.  axis-tools.jar : java2wsdl, wsdl2java? [maybe core of these goes in
> 'axis.jar', but not standalone programs].

+1. A separate axis-tools.jar is good.

NB, Say I was to start creating a version of the ant tasks for (2), what
is
a good directory tree for it
I was thinking  java/tools/ant/ so one could later do java/tools/taglib or
java/tools/xdoclet or whatever

these may devolve into separate deliverables, axis-antlib.jar,
axis-taglib.jar, etc.

> 3.  axis-opt.jar : we have 'many' tools that are outside the charter of
> 'axis' (this could be argued... let's not :-) that some users MAY choose
> to use.  Great, on the one hand, but other users see these as both
> unnecessary overhead and security concerns (think corporate world,
> controlled production environments, etc - no loose ends).

=0

> 4.  axis-dev.jar : Other tooling useful for AXIS user-developers & AXIS
> developers: log4j.properties?, SimpleAxisServer (read the javadoc!),
local
> transport support?

+1; though a good jetty hosted server may move into axis server.

>
> As a side benefit, this will help draw *clear* lines between various
> components in the system.

I think a client/server split may also be appropriate, with axis-core
containing everything a client needs, but axis-server adding server
specifics. This keeps the client download skinny.

now, counter arguments against change

-more separate jars means version conflics inside axis itself from users
who
get things wrong (imagine tomcat4\common\lib having axis-core1.1 but the
WAR
includes the 1.2 version of everything.

-confusion as to whether optional stuff is needed or not.

The other way of supporting (3) is having a central config point for
security, letting them turn off any helpful but insecure features in
single
place.







Mime
View raw message