Main New Features:
Granite Data Services 2.0.0 Release Candidate 1 has just been released and comes with four main new features:
- Google App Engine support: GDS applications may now be deployed on Google's infrastructure. See details in William's related posts on this blog.
- Servlet 3.0 preview: Gravity now implements data push with Servlet 3.0 API and may be tested with Glassfish v3 preview (lastest promoted builds only). See below for details.
- Configuration MBeans: you may now use your JMX console in order to manage several GraniteDS options and watch for runtime configuration details. See below for details.
- JDO annotations support: Gas3 now generates suitable ActionScript3 code for JDO annotated entities and the DataNucleusExternalizer takes care of JDO's specific annotations.
The granite-config.dtd has changed in order to make the config more readable: as a general rule, all configuration attributes use now a "dashed" convention: "annotedwith" is now spelled "annotated-with", "instanceof" "instance-of", etc. There is also a new "gravity" section whose meaning content is detailed in "Gravity Changes" below.
The new DTD is online here and will help you with a DTD aware XML editor.
Gravity Changes:
Gravity code was getting messy, with several duplicated source sections, and hard to maintain. With the addition of Servlet 3.0 and GAE support, things were going even more harder, so the code has been cleaned up and widely refactored. However, the new code has been fully tested and shouldn't bring any problem.
A new feature in this rewriting is the use of a thread pool for publishing messages. Previously, a published message was delivered to subscribed channels in a synchronous way, using the publish request container thread (delivering means only duplicating the message for all channels subscribed to the message's topic and adding each copy to each channel's queue). This operation was potentially time consuming with a large number of channels connected to the same topic and could block the caller container thread for a significant amount of time. A thread pool is now used for that purpose in all servlet implementations (Tomcat, JBossWeb, Jetty and Servlet 3.0) except for GAE.
Instead of servlet parameters, Gravity configuration now goes in a dedicated section of granite-config.xml. Here is an example of all options with there default values:
<gravity
factory="org.granite.gravity.DefaultGravityFactory"
channel-idle-timeout-millis="1800000"
long-polling-timeout-millis="20000"
reconnect-interval-millis="30000"
reconnect-max-attempts="60">
<thread-pool
core-pool-size="5"
maximum-pool-size="20"
keep-alive-time-millis="10000"
queue-capacity="2147483647" />
</gravity>
This section is purely optionnal and you may omit it if you accept default values. Full documentation will be provided later but here is some comments on the most important options:
- channel-idle-timeout-millis: the elapsed time after which an idle channel (pure producer or dead client) may be silently unsubcribed and removed by Gravity. Default is 30 minutes.
- long-polling-timeout-millis: the elapsed time after which an idle connect request is closed, asking the client to reconnect. Default is 20 seconds. Note that setting this value isn't supported in Tomcat/APR configurations.
- thread-pool attributes: all options are standard parameters for the Gravity ThreadPoolExecutor instance.
Servlet v3 support is new in this RC1 and should be considered as beta software. The only up-to-date implementation of the new API at this time is in Glassfish v3 trunk and you may download it here (Servlet 3.0 support has been tested with glassfish-v3-preview-b47-windows.exe and may or may not work with other builds).
Configuring the GDS chat sample for Glassfish v3 is a two steps process:
- Edit the graniteds/examples/env.properties and set SERVER_HOME to your glassfishv3/glassfish directory and SERVER_HOMER_DEPLOY to ${SERVER_HOME}/domains/domain1/autodeploy.
- Copy the content of the graniteds/examples/graniteds_chat/resources/WEB-INF/servlet3-web.xml into the web.xml file. Then, use the "deploy" target of chat build file and start Glassfish (see Glassfish documentation).
Configuration MBeans:
This RC1 comes with two new MBeans for GDS runtime management:
- GraniteConfig MBean: this mbean will show an almost complete configuration state of GDS at runtime, with several things that were not accessible previously (except with a debugger): externalizers used so far, associated with serialized classes, enabled or disabled Tide components, etc. The only available operation provided by this MBean is a reload button: it will re-read your deployed granite-config.xml file and take care of your modifications. Note that everything may not be reconfigured at runtime but this may be at least a great tool for finding issues, for example, with externalizers configuration.
- GravityConfig MBean: this mbean will display the current state of Gravity, letting you modify at runtime timeouts and pool sizing. You'll be also able to restart Gravity: note however that this is only an emergency feature because all undelivered queued messages will be lost!
2 commentaires:
Does the appengine support work with the latest 1.2.1 version of appengine? I noticed all the example code is using 1.2.0 of appengine.
As far as open source options are considered WSO2 Data Services server [1] is emerging with rapidly growing community. It has following features.
Multiple datasource support:-
Supports multiple datasource types including any relational database accessible via JDBC,CSV, Excel, JNDI bound data sources and Google Spreadsheets
WS & REST interfaces:-
Data can be exposed as WS-* style web services or REST style web resources
Customizable Response format:-
The response XML data can be customized to match your next adaptor's input
Support for Large data sets:-
With XML streaming in place, a large data set can be sent as response without having any significant impact to server's memory usage
Nested Queries:-
A Query can be nested within another making it possible to call the former with the results of latter. The nested queries do not need to point to same data source. Thus this allows generating federated response out of disparate data sources.
Role based content filtering:-
Role based content filtering allows same service to be accessed by different permission levels, yet only exposing the data elements configured to be seen by that particular role
Security :-
Full support for WS-Security,WS-Trust,WS-Policy, WS-Secure Conversation & XKMS
Web based GUI wizard
Using GUI wizard, you can expose data as Web services on the fly. The UI fully supports configuring security, access throttling and other QoS features as well.
Multi transport support:-
Send and receive data in either HTTP/S, SMTP, JMS or XMPP
[1] http://wso2.com/products/data-services-server/
Enregistrer un commentaire