Re: xmlBlaster Java-Package structure

[Marcel Ruff <ruff at swand.lake.de>]

manuel Kron wrote:
> 
> Hi,
> 
> i would like to change the java-package namespaces into :
Yes, it is perhaps a good idea to clean up the packages again.
Now that we know quite well where we want to go.


> 
> --------- new package namespaces ---------
> 
> ---- for servers-------
> org.xmlBlaster.mob
> org.xmlBlaster.mob.engine
> org.xmlBlaster.mob.query
> org.xmlBlaster.mob.ums.authentication
> org.xmlBlaster.mob.ums.authenticate
> 
> org.xmlBlaster.mob.persistence
> org.xmlBlaster.mob.persistence.filestore
> org.xmlBlaster.mob.persistence.xmldb
> org.xmlBlaster.mob.persistence.oodb]
> 
> org.xmlBlaster.mob.transaction
> org.xmlBlaster.mob.transaction.jts
> 
> 
> ----- for clients -------
> org.xmlBlaster.mobi
> org.xmlBlaster.mobi.corba
> org.xmlBlaster.mobi.ftp
> org.xmlBlaster.mobi.http
> org.xmlBlaster.mobi.wap
> org.xmlBlaster.mobi.email
> org.xmlBlaster.mobi.native                 <<--- For the server logic
> on the same host
> 
> 
> org.xmlBlaster.util
> org.xmlBlaster.util.xmlWrapper
> 
> --------------------------------------
> 
> MOB
> ----
> MOB means : message oriented broker
> The programming model of the xmlBlaster is to exchange
> messages. Not like RPC (e.g. CORBA), which programming
> model is CORBA or RMI...
> 
> MOBI
> -----
> MOBI mean : message oriented broker interface
> Each client can use this interface to transfer xml-messages
> through the MOB (Message-oriented Broker).
> 
> UMS
> ----
> UMS means : user management system
> 
> Please look at  slide show page 8,9,12,13,14.
> I think the package names mob, mobi and ums serves for better
> structure in the xmlBlaster Javacode.
> 
> WHAT DO YOU THINK????
> Please answer... thanks...

1. simple names:
----------------
I would replace following names:

MOB  ->  engine or server
MOBI ->  interface
UMS  ->  user

minimizing shortcuts.

A new developer has to find her way throu many
shortcuts like CORBA,XML,ORB,IIOP,XSL,XPATH ...
and i believe we shouldn't introduce more.

A major effort should now be to keep everything as
simple as possible.

Reading official CORBA drafts always gives me some major
headache, we have to find some *much* simpler approach.


2. The UMS (user) package:
--------------------------
Maybe it would be a good idea to place this package
under org.xmlBlaster.
This could enforce the goal, to allow to plugin an
exiting authentication/authorization system like LDAP
or a proprietary Orcale DB or what ever.
We would implement a reference implementation (see a former
email) using - you guessed it - an instance of xmlBlaster.

Does everybody know the terms authentication/authorization?

authentication == Who are you?
authorization  == What are you allowed to do? (ACL - access control
lists)

What about replacing the package name
   'authentication' by 'login'
and
   'authorization' by 'access'


3. Package example:
-------------------
org.xmlBlaster.server

org.xmlBlaster.server.persistence
org.xmlBlaster.server.persistence.filestore
org.xmlBlaster.server.persistence.xmldb
...
 
org.xmlBlaster.server.transaction
org.xmlBlaster.server.transaction.jts

org.xmlBlaster.user.login
org.xmlBlaster.user.login.native
org.xmlBlaster.user.login.ldap
org.xmlBlaster.user.login.jdbc
...

org.xmlBlaster.user.access
org.xmlBlaster.user.access.native
org.xmlBlaster.user.access.ldap
org.xmlBlaster.user.access.jdbc
...


# This contains the server skeletons,
# and the server implementation, which
# are used by clients to acces xmlBlaster:
org.xmlBlaster.interface
org.xmlBlaster.interface.server.corba
org.xmlBlaster.interface.server.wap
...
 

# This is a client callback interface,
# but the server implementation of it.
# xmlBlaster can use this to call back to
# a client:
org.xmlBlaster.interface.callback
org.xmlBlaster.interface.callback.corba
org.xmlBlaster.interface.callback.email
....

org.xmlBlaster.interface.user.login
org.xmlBlaster.interface.user.login.corba
org.xmlBlaster.interface.user.login.ftp
...

org.xmlBlaster.interface.user.access
org.xmlBlaster.interface.user.access.corba
org.xmlBlaster.interface.user.access.ftp
...

# These util classes are used by xmlBlaster
# but may be usefull for clients as well.
org.xmlBlaster.util
org.xmlBlaster.util.xml
org.xmlBlaster.util.log

# Some helper for Java clients, that not
# every developer needs to invent the wheel again:
org.xmlBlaster.clienthelper
org.xmlBlaster.clienthelper.xml


Some third party feelings about this would be
*very* welcome.

Marcel

-- 
Marcel Ruff
ruff at swand.lake.de
http://www.lake.de/home/lake/swand/
http://www.xmlBlaster.org