axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Jordahl <t...@macromedia.com>
Subject RE: [axis] User Roles and AXIS components
Date Fri, 16 Aug 2002 16:53:41 GMT

+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