[Productivity] Level 4 - Production

[asoldano]

This thread is about the last level of productivity efforts we're thinking about. Please refer to this http://www.jboss.com/index.html?module=bb&op=viewtopic&t=121127 for a topic introduction.

Having a webservice system finally live in production environment requires system administrators to deal with a lot of new issues. Topics like security, accountability, statistics, availability, SLA considerations and so on are most likely to come out especially considering the role webservices play in a SOA.

[asoldano]

What are we going to do?

Once again, documentation will be the starting point. Users have to be aware of the issues they'll have to cope with before their system actually switch to the production environment.

Thinking about the SOA governance issues, I believe webservices should at least come with some basic tools for service customer discovery and performance/level of service checks.
My idea is to start from the jmx-console that actually show some metrics about the endpoints and enhance them, adding more info about load, response time, etc. as long as statistics/log about clients calling each endpoint. The administrator should be able of course to enable/disable metrics recording, etc; moreover we might provide info at different scopes (i.e. statistics for each endpoint as well as for each operation, etc.).
The idea is that the administrator of services deployed on a given host should be able to track who is actually using the service and how. Moreover, he should be allowed to check whether the system is overloaded or not (that is: he meet the SLA requirements) and I think it's fine to check this at the WS level since services are the entry point for customers.
Also showing the policy deployed on each policy subject might be useful.

Finally, some efforts should be put on registry/UDDI. In my previous experiences registry usefulness was often underestimated; however registries may really help with painful issues, like wsdl versioning. I'm going to further elaborate my thoughts about this in the next future; for sure registries are going to be involved at least in one of the advanced samples backed by scenarios I previously talked about.

Many other issues might be interesting at this level; if you think something else is more important or urgent, feel free to comment.

[maeste]

Hi all,

Very very busy in last weeks, I found time just now to give my two cents.
What I would jbossws provide at this level is a sophisticated log system, giving me the opportunity to understand who is using my service and how.
My idea is to provide a log (and docs to explain how to enable/disable or set a dedicated file and so on) awstats compatible. I know awstats is designed for web apps, but I think you (we if I get time to contribute) can think how to provide compatible logs, because it is grat for immediate statistic and graphs.
In a SOA world we have to consider stats and graphs for the management have to consider service level since service is becoming the access to the businness (as web have been until now).
Of course this kind of feature and all which could be thought at this level have to consider not only jbossws services but probably more general SOA services (I'm thinking to ESB too).

[asoldano]

Hi Stefano,

"maeste" wrote:
What I would jbossws provide at this level is a sophisticated log system, giving me the opportunity to understand who is using my service and how.
My idea is to provide a log (and docs to explain how to enable/disable or set a dedicated file and so on) awstats compatible. I know awstats is designed for web apps, but I think you (we if I get time to contribute) can think how to provide compatible logs, because it is grat for immediate statistic and graphs.

Graphical stats have the plus of being really powerful in providing informations in a way that is both brief and effective. For this reason I like your idea of giving the ws administrator a mean of viewing stats graphically.
We have to think how this could be achieved; for example the informations we are interested in might be not all in the http header; most probably we would have to create a new log format and something able to deal with it (perhaps using awstat).

Anyway, generally speaking, I think the idea of having something like a WS log repository to query with different filters for getting informations on both pre-defined and custom (the admin decides through the jmx-console) time period is definitively interesting.

[asoldano]

Anyway, generally speaking, I think the idea of having something like a WS log repository to query with different filters for getting information on both pre-defined and custom (the admin decides through the jmx-console) time period is definitively interesting.

Some further thoughts on the ws log repository idea; this could be directly linked to what is written here http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115661, that is in/out messages are captured by a RequestHandler as long as information about processing time, client IP and the receiving host. This data is then persisted (no data loss with server shutdown and/or redeployment, eventual support for cluster...). JMX-console allows to query those data and to start/stop log recording as long as setting how much info is to be saved. Query could even be based on the soap body, depending on how it is stored.
Converter to stardard log formats could perhaps be added to allow eventual batch analysis and creation of graphical statistics / table, etc.
Up to this, logs would be stack independent (Native, Metro, CXF). As far as I can see, adding more specific and interesting data (operation statistics, ws-security related info, etc.) could be possible with native stack, since it will require at least access to the metadata model. However this could be further investigated.