Feature evaluation/missing features

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature evaluation/missing features

Hubert, Eric
Hi all,

I'm currently in the process of evaluating different service routing
solutions. We have identified the following important requirements for
our environment:

- must be very fast and suitable for service calls from webpages
- central control of all service endpoints
- centralized routing
- availability control of all services
- usage statistics of all services
- a role-based routing administration, grouping of services
- distribute services on different nodes (dynamic changes; add/remove
without restart)
- highly available (24/7)  

>From a first glance on Apache Synapse and the WSO2 admin GUI it looks
very promising. I'm only sceptical about the role based administration
and high availability. All other requirements seem to be met. Or what do
you think? As the whole project is Open Source we would be willing to
dedicate some man power to help implementing missing features, if we
come to the conclusion, that it offers a strong base for us.

For example the role based administration is very important. At the
moment there is no user management or did I oversee something?
In our usage scenarios a certain admin may only be allowed to administer
a single service or a group of well defined services, but not all. It
would also be very useful if one could define custom roles encapsulating
a set of user rights. These role-based rights should only be a superset
of concrete rights this admin may have on a set of certain services.
What do you thing about such an addition? I think it would be useful for
many corporate users.

Could someone please elaborate on high availability aspects! Is it
ingenuous to think that everything is stateless and one could run the
ESB on different nodes accessing a shared storage? Of course, it has to
be assured that write access to the shared storage is only done from one
node at a time. But this should only be needed for administrational
purposes, or am I wrong?

Regards,
  Eric

_______________________________________________
Esb-java-user mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
Reply | Threaded
Open this post in threaded view
|

Re: Feature evaluation/missing features

asankha
Hi Hubert
> >From a first glance on Apache Synapse and the WSO2 admin GUI it looks
> very promising. I'm only sceptical about the role based administration
> and high availability. All other requirements seem to be met. Or what do
> you think?
Yes, you are correct. In fact we are currently working on bringing in HA
support and clustering for the ESB. We already have some changes checked
into the trunk that allows for clustered caching etc.
>  As the whole project is Open Source we would be willing to
> dedicate some man power to help implementing missing features, if we
> come to the conclusion, that it offers a strong base for us.
>  
Yes, all our code is under ASL 2.0 and we maintain our code, issues and
wiki in public, and we could welcome any new contributors to the
project. Similarly to Apache, one could become a committer for the WSO2
ESB and other projects as well, and gain direct access to the code for
modifications once you are accepted as committers.
> For example the role based administration is very important. At the
> moment there is no user management or did I oversee something?
>  
You are correct, however we have plans to integrate with the WSO2
Identity management solution for some of this functionality.
> In our usage scenarios a certain admin may only be allowed to administer
> a single service or a group of well defined services, but not all. It
> would also be very useful if one could define custom roles encapsulating
> a set of user rights. These role-based rights should only be a superset
> of concrete rights this admin may have on a set of certain services.
> What do you thing about such an addition? I think it would be useful for
> many corporate users.
>  
Yes, this would be a useful feature for many
> Could someone please elaborate on high availability aspects! Is it
> ingenuous to think that everything is stateless and one could run the
> ESB on different nodes accessing a shared storage? Of course, it has to
> be assured that write access to the shared storage is only done from one
> node at a time. But this should only be needed for administrational
> purposes, or am I wrong?
>  
Generally the ESB could be clustered for HA, however there will be some
limitations on the failover and retry aspects. For example, if a server
is to crash once a client makes a http connection to an ESB node, there
is no way another node could take over and reply over the same tcp
socket. This may be true in the case of request-response JMS call as
well, where the ESB would post a request to a Queue and wait for a
response with the same correlation ID using a filter etc. Even in this
case, we have certain limitations. We are also currently looking at
providing JTA support for services, so that JMS transactions that fail
etc. could be retried. We are also working on how we could bring down
the http/s transports into maintenence mode, such that we prevent
accepting new connections on the tcp socket/s but continue serving
in-flight requests until the system can be safely shutdown. This allows
a load balancer in front to safely let a node be taken down for
maintenance as it would see it as being down as it doesn't accept new
connections etc.

Most of the core code for the WSO2 ESB resides under the Apache Synapse
project, and thus it would be interesting for you to have a close look
into that as well. We look forward to interacting with you in the future

asankha

_______________________________________________
Esb-java-user mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user