Hi Eric
I only have a few concerns. When designing the new UI please always
take in mind that some users are going to manage a lot of objects in
their configuration. The UI should support this. Please consider
something like 100 services, 500 endpoints, 20 cases within a
switch-mediator and so on. The UI should also be usable with these
numbers. Therefore it would be a good idea to create different
configuration sets to test the UI with. Please try to keep the size of
symbols not to large, otherwise it might get problematic for larger
configuration. Maybe it would be possible to use some kind of
zoom-mechanism for the design view to balance between few and many
items on the screen.
This is excellent feedback.. and having sample datasets for
visualization will surely help us a lot
It would also be very helpful to offer filters and/or grouping
mechanisms to reduce the number of displayed items in lists (like a
list of services/endpoints). Regarding proxy services I’m always
thinking about logical groups, to be able to form a tree. This way it
would be possible to categorize and quickly access service
definitions. This would match your idea regarding the tree, if I got
it right.
We thought of pagination, but I guess a simple regex filter with
pagination would allow services, endpoints etc to be filtered and
displayed better.. A logical grouping of services already exists as
ServiceGroups in Axis2 land.. we will think how best a grouping could be
achieved
So far you screens only contain detail views (besides the endpoint
overview). I would be very interested in some more sample screens of
overview pages (those pages from which you enter the detail pages to
edit an existing sequence, proxy service or endpoint). Having more
than 20 items a plain ordered list without grouping or filtering is
not convenient enough.
These would be generally tabular, with filtering (as you suggested) and
pagination..
Besides the UI improvements which basically concentrate on better
usability I see the following important other points. Maybe you can
also address some of those:
- user/role-based access, differentiate at least three roles:
o Server Administrator (read/write server configuration, e.g.
axis2.xml, synapse.properties etc.)
o Service Administrator (read/write service configuration,
synapse.xml, registry etc.)
o User (read-only service configuration
o a user can haven multiple roles
- possibility to bundle changes (decouple saving and
applying), version changes
We actually discussed something around this.. the idea is to basically
start with a clone of the current configuration when a user "locks the
current configuration for editing". This will start a synapse.xml.work
(or something) and then all edit actions could take place on it, without
touching the active configuration. If the user is satisfied, he can
"activate" the config or "release" all he did and forget the changes.
This would also allow us to possibly validate a configuration before
application.
The next item we discussed was that it would be cool to "import" a
configuration fragment over the current configuration (following whats
described above). So one could provide a synapse.xml.n to be merged into
the main synapse.xml, or maybe provide a configuration bundle like a Jar
file for a proxy service, which could then be imported into the
configurtation.
- server/cluster management
o configure server settings (ports and other settings from
axis2.xml, synapse.xml, server.xml etc.)
o show status of nodes, allow stop, start, and restart
o manage cluster members (definition of axis2.xml)
o UI for integrated JMX-support
Although I fully agree that these changes are helpful and required.. I
think we would want this done at the generic WSO2 framework layer. To
better explain, we are trying to integrate the WSO2 Data services, WSAS
etc functionality and make these available to an ESB user if he desires
to use it. Hence we are re-engineering some of the code to be reusable
across products.
- cluster support for service management
o apply changes cluster-wide (graceful restart of a whole cluster)
I think this type of a change is best performed via JMX..? We could also
consider this at the framework level, and we will discuss your
suggestions with the other teams.
thanks
asankha
--
Asankha C. Perera
WSO2 - http://wso2.org
http://esbmagic.blogspot.com
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
