[axis] User Roles and AXIS components

[rs...@us.ibm.com]

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]

Arguably, the single most important role is (4) - and much effort *is* 
being expended to satisfy this.

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).

The axis.jar contains element that facilitate each of these to varying 
degrees, but not always in a way that is desirable for the end users 
(2,3).

I believe that AXIS can, and should, be *usable* with MINIMAL 
configuration/settings out-of-box for both (2) and (3).

I'd like to start by proposing that we break axis.jar apart using the 
following guidelines:

1.  axis.jar : Core runtime components (standalone to satisfy (3)) - 
nothing in here should make a admin/security-guru uncomfortable.
2.  axis-tools.jar : java2wsdl, wsdl2java? [maybe core of these goes in 
'axis.jar', but not standalone programs].
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).
4.  axis-dev.jar : Other tooling useful for AXIS user-developers & AXIS 
developers: log4j.properties?, SimpleAxisServer (read the javadoc!), local 
transport support?

Developer support (i.e. setting 'local' transport, others?) can be 
introduced using pluggable startup logic: axis-dev.jar would provide the 
appropriate plugs and config so that it defaults to keep developers happy. 
  Remove axis-dev, and you fall-back to reasonable defaults/environs for 
end-user runtimes.

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

<ras>

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

Re: [axis] User Roles and AXIS components

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: <rs...@us.ibm.com>
To: <ax...@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.