With my last session of the conference I decided to throw myself into the deep end completely and attended a hard core Red Hat session. I can see I really am going to have to work on my Red Hat skills quite a lot before doing this again, but anyway here are some points that I have picked up either from this session and from various conversations throughout the conference.
Red Hat Enterprise 5, the next release, is likely to include some substantial improvements.
iSCSI : low cost enterprise SAN connectivity
NFSv4
LVM2 : to include cluster wide snapshots
Application failover is possible when the correct start, stop and status scripts are available for the software. Some other features such as Membership, I/O Fencing, Lock Management and Heartbeats were discussed. I can imagine what some of these are when relating them to the JBoss clustering approach, but I was unable to follow the specifics. Two things which I did pick up on were STONITH (Shoot The Other Node In The Head?) and Lock Management.
STONITH is basically support for management cards that allow machines to be rebooted remotely. This is a well developed aspect of Red Hat which a member of the audience asked about.
Lock Management in clustered environments was previously made possible by a single lock manager. This has now been re-engineered so that each node has its own lock manager (DLM - Distributed Lock Management). This feature is new with Cluster Suite v4 and has brought enormous performance improvements.
The latest version of the Cluster Suite and Global File System have been shown to scale to 300 nodes in testing, but Red Hat are looking for a customer with a larger network to prove that it can scale beyond this.
The Global File System will now support 16TB on 32 bit systems, and 8EB on 64 bit systems.
Red Hat have had their Virtualization software on display at their stand. Apparently all the DVDs they wanted to bring are lost in transit somewhere so it looks like a download will be necessary to try this out for myself. They took great please in launching and destroying a Windows Vista virtual machine on the demonstration system. Virtualization support is, or will be, available in the Fedora distribution, meaning it's free for everyone and not just a part of the Enterprise suite.
The intent with future releases of Red Hat is to be able to replicate entire memory spaces from machine to machine, making it possible to provide fault tolerance for legacy systems far more easily. I'm not sure what kind of timescales may be on this, it sounds quite ambitious.
In conclusion, I needed a coffee badly.
Friday, November 24, 2006
JBossCache Advanced - Manik Surtani
At the start a diagram was displayed showing the stack. Broadly speaking it was shown that JGroups formed the base of the stack with various components, including JBossCache and Messaging (a new addition) plugged into it.
Clustering supports a variety of features, including the various flavours of HA services (High Availability) such as HA-Singleton, HA-Remoting, etc.
The application stack was defined as follows:
Application
Building Blocks
Channel
GMS
Unicast
NAKACK
FD
UDP
Physical Transport
Custom Channel implementations can be written, they are similar in nature to MulticastSocket.
The remainder of the session was spent describing in a little more detail 4 of the main areas; JGroups, JBossCache, PojoCache and HA services.
1. JGroups
Supports : UDP (IP Multicast), TCP and TCP NIO.
Note: TCP requires a dedicated thread per connection whereas NIO has been tweaked to use a connection pool.
Reliability : automatic retransmission
Ordering : FIFO, TOTAL
Failure Detection : using a heartbeat or ping approach
Group Membership
Fragmentation : allowing messages to be broken down into smaller units for transmission
Encryption, authentication : related to group membership
Compression, message batching : the example of compressing XML was used
State transfer : session replication
Merging after network partitioning : described as recovery from network faults such as failed routers
Flow control
2. JBossCache
.... some more to add ....
Clustering supports a variety of features, including the various flavours of HA services (High Availability) such as HA-Singleton, HA-Remoting, etc.
The application stack was defined as follows:
Application
Building Blocks
Channel
GMS
Unicast
NAKACK
FD
UDP
Physical Transport
Custom Channel implementations can be written, they are similar in nature to MulticastSocket.
The remainder of the session was spent describing in a little more detail 4 of the main areas; JGroups, JBossCache, PojoCache and HA services.
1. JGroups
Supports : UDP (IP Multicast), TCP and TCP NIO.
Note: TCP requires a dedicated thread per connection whereas NIO has been tweaked to use a connection pool.
Reliability : automatic retransmission
Ordering : FIFO, TOTAL
Failure Detection : using a heartbeat or ping approach
Group Membership
Fragmentation : allowing messages to be broken down into smaller units for transmission
Encryption, authentication : related to group membership
Compression, message batching : the example of compressing XML was used
State transfer : session replication
Merging after network partitioning : described as recovery from network faults such as failed routers
Flow control
2. JBossCache
.... some more to add ....
Wednesday, November 22, 2006
JBossWorld Party
It was a long day, lots of sessions, the Customer Panel, and then at the end of the day finding only light snacks rather than the full blown meal we had received the day before.
I got talking to a delegate from Camden Council whilst looking rather despondently at the nibbles, but was saved from starvation by the JBossWorld Party. If you want to know more I'll happily oblige, it was an amazing show; food, drinks, cocktails, dance routines, birthday cake ... all the usual things :)
I got talking to a delegate from Camden Council whilst looking rather despondently at the nibbles, but was saved from starvation by the JBossWorld Party. If you want to know more I'll happily oblige, it was an amazing show; food, drinks, cocktails, dance routines, birthday cake ... all the usual things :)
Web Services Advanced - Thomas Diesler
It was perhaps a little unwise of me to throw myself into this session given how rusty my webservices are. Note to self: read more. This was compounded by the fact that JBoss have, as with so many other functional areas, apparently given this a serious overhaul. In addition it was mentioned that regular "plugfests" were being held with Microsoft to ensure interoperability.
Anyway, battling on, an impressive list of areas were walked through, some of which I will cover in more detail than others. I will revisit this and several other posts later on to provide links to online sources.
1. WS-Security
# Following the OASIS standards: SOAP, Token, REL and SAML (Important for SSO), W3CXML Encryption Signature
This is configured within within ... I need to locate the relevant config file ...
In a little more detail this area includes:
# Strong encryption
# Certificate authentication, signed content and public key infrastructure.
# JAAS integration
# Fine grained operation configuration
# Fine grained message element configuration
# Message expiration
# Interoperability with Microsoft WSE and Sun JWSDP
The key thing here was that this relates to securing the XML payload on the message and not on the transport. The scenario discussed described messages being recieved and stored by a relay for future transmission onto the destination. In this case the data remains secure whilst on the relay, and the transport could be open (HTTP) without breaching security of the data at any stage.
One warning that was given was to always consider the necessity for encryption, and whether it should be supplied within the message or on the transport given that the performance costs are quite different in each case. This overhead is one reason why WS-SEcurity supports fine grained control of message elements, meaning that messages need only be partially encrypted.
2. WS-Addressing
This refers to moving message addressing information out of the headers (as with cookies) and into the message body, making the message aware of its own routing needs. This allows applications to much more easily control message routing through standardised xml tags.
One advantage of this feature that was briefly described was the ability to dynamically assign "reply" and "fault" addresses for messages.
3. Message Transfer Optimization Messaging (MOTM) and XML Optimized Packaging (XOP)
Refering to the ability to encode binary data in base64 format automatically for transmission. Data formats currently supported include JPEG, text/XML, app/XML.
We were told that XOP is configured as a default within JBoss and that put simply, it handles base64 encoding so you don't have to.
4. JAXWS
Towards the end of the session some mention was made for Providers to be implemented as Message or Source. It appears that Source implementations are those that are able to work directly on the message payload, whereas those that are Message get access to the entire XML structure.
JBoss5 is said to be about 80% compliant with this standard at present, whereas JBoss4 is around 20% compliant
5. And Finally ...
Future consideration will be given to back porting the latest webservices technologies into JBoss4, but JBoss are not sure this will be technically possible. Other things being considered for the future include WS-ReliableMessaging and Fast Infoset.
Samples and documentation are high on the agenda. I look forward to these given how rusty my webservices knowledge is.
The key points for me were around the fine grained control of encryption within the message which is transport independent, the ability to work directly on the message payload, and the ability to auto-magically encode binary data.
Anyway, battling on, an impressive list of areas were walked through, some of which I will cover in more detail than others. I will revisit this and several other posts later on to provide links to online sources.
1. WS-Security
# Following the OASIS standards: SOAP, Token, REL and SAML (Important for SSO), W3CXML Encryption Signature
This is configured within within
In a little more detail this area includes:
# Strong encryption
# Certificate authentication, signed content and public key infrastructure.
# JAAS integration
# Fine grained operation configuration
# Fine grained message element configuration
# Message expiration
# Interoperability with Microsoft WSE and Sun JWSDP
The key thing here was that this relates to securing the XML payload on the message and not on the transport. The scenario discussed described messages being recieved and stored by a relay for future transmission onto the destination. In this case the data remains secure whilst on the relay, and the transport could be open (HTTP) without breaching security of the data at any stage.
One warning that was given was to always consider the necessity for encryption, and whether it should be supplied within the message or on the transport given that the performance costs are quite different in each case. This overhead is one reason why WS-SEcurity supports fine grained control of message elements, meaning that messages need only be partially encrypted.
2. WS-Addressing
This refers to moving message addressing information out of the headers (as with cookies) and into the message body, making the message aware of its own routing needs. This allows applications to much more easily control message routing through standardised xml tags.
One advantage of this feature that was briefly described was the ability to dynamically assign "reply" and "fault" addresses for messages.
3. Message Transfer Optimization Messaging (MOTM) and XML Optimized Packaging (XOP)
Refering to the ability to encode binary data in base64 format automatically for transmission. Data formats currently supported include JPEG, text/XML, app/XML.
We were told that XOP is configured as a default within JBoss and that put simply, it handles base64 encoding so you don't have to.
4. JAXWS
Towards the end of the session some mention was made for Providers to be implemented as Message or Source. It appears that Source implementations are those that are able to work directly on the message payload, whereas those that are Message get access to the entire XML structure.
JBoss5 is said to be about 80% compliant with this standard at present, whereas JBoss4 is around 20% compliant
5. And Finally ...
Future consideration will be given to back porting the latest webservices technologies into JBoss4, but JBoss are not sure this will be technically possible. Other things being considered for the future include WS-ReliableMessaging and Fast Infoset.
Samples and documentation are high on the agenda. I look forward to these given how rusty my webservices knowledge is.
The key points for me were around the fine grained control of encryption within the message which is transport independent, the ability to work directly on the message payload, and the ability to auto-magically encode binary data.
JBoss Federated SSO Framework - Anil Saldhana and Sohil Shah
Much as with the previous session this proved immensely popular, but additional seating was provided so I managed to avoid sprawling on the floor at the back this time. Identity Federation is currently the domain of commercial vendors so it is hardly surprising that so much interest was shown around this subject, what was surprising was the low key manner with which it has been approached within the conference.
The benefits of SSO (Single Sign On) were described as follows:
Consolidation of identity stores
Improvements in user account provisioning
An improved user experience
Improved efficieny in the integration of new applications
Enabling secure inter-company application access
The architecture consists of 3 elements:
Token Marshalling: Kerberos, SAML, other pluggable formats. This is a configuration feature which is then managed automatically for the developer.
The Identity Management Framework: OpenLDAP by default, but this is pluggable and can support custom operations such as JDBC.
The Federation Server: which manages secure cross-domain identity propagation.
A demonstration was provided where two JBoss web applications running in their own independent JVM's where shown to support identity federation, logging in on one application and being auromatically logged in on the other, logging out on one and being automatically logged out on the other.
The developers described 4 key steps within the demonstration code:
1. Implementation of a LoginProvider to perform authentication.
2. Registration of the LoginProvider within the "sso.cfg.xml" file inside "jboss-sso.sar/conf".
3. Configuring the SSO Trust Server for your domain within this same config file.
4. Configuring the web app to activate federated SSO.
This last point could mean using JAAS, or some non-JAAS solution such as a Struts Action class. In the non-JAAS case it was said that 3 Tomcat valves would need to be configured. I imagine a trip through the demonstration code supplied on the web site would be best given that much of what was talked about related to the configuration of one aspect of the application server or another.
Areas which are being looked at for the future include integration with more specifications such as WS-Security, WS-Trust, WS-Federation, WS-Policy; support for Certificate based and SRP protocols; and cross system password synchronization.
The benefits of SSO (Single Sign On) were described as follows:
Consolidation of identity stores
Improvements in user account provisioning
An improved user experience
Improved efficieny in the integration of new applications
Enabling secure inter-company application access
The architecture consists of 3 elements:
Token Marshalling: Kerberos, SAML, other pluggable formats. This is a configuration feature which is then managed automatically for the developer.
The Identity Management Framework: OpenLDAP by default, but this is pluggable and can support custom operations such as JDBC.
The Federation Server: which manages secure cross-domain identity propagation.
A demonstration was provided where two JBoss web applications running in their own independent JVM's where shown to support identity federation, logging in on one application and being auromatically logged in on the other, logging out on one and being automatically logged out on the other.
The developers described 4 key steps within the demonstration code:
1. Implementation of a LoginProvider to perform authentication.
2. Registration of the LoginProvider within the "sso.cfg.xml" file inside "jboss-sso.sar/conf".
3. Configuring the SSO Trust Server for your domain within this same config file.
4. Configuring the web app to activate federated SSO.
This last point could mean using JAAS, or some non-JAAS solution such as a Struts Action class. In the non-JAAS case it was said that 3 Tomcat valves would need to be configured. I imagine a trip through the demonstration code supplied on the web site would be best given that much of what was talked about related to the configuration of one aspect of the application server or another.
Areas which are being looked at for the future include integration with more specifications such as WS-Security, WS-Trust, WS-Federation, WS-Policy; support for Certificate based and SRP protocols; and cross system password synchronization.
JBoss Security - Anil Saldhana
Security is an area of JBoss that is being overhauled / re-written to an enormous extent. The sessions I attended were not announced as being part of the main product stream, yet we ran out of chairs in rooms which became stifling with the number of people that were packed in. Knowing the shortage of good open source initiatives in this area it is hardly surprising for me, but it would certainly appear that JBoss underestimated the interest around the subject.
This introductory session talked around the work that was ongoing, and gave an overview of the direction the team was taking with Security. I did then attend the advanced session around SSO which showed a working example, more on that in the next report.
The Security 2.0 Beta which is currently available includes SPI and an initial version of JBossSX, version 2.0 then is expected to include Identity Federation and a cleanup of SPI, at version 2.1 we should see SAML support which will make the Security module standards compliant for SSO.
The default distribution within JBoss 5.0 is apparently written to work with OpenLDAP, but this is a pluggable architecture meaning we could use JDBC ontop of our own identity store (Oracle) should we wish. Configuration changes where shown to have been made around the "login-config.xml" file.
Following a number of discussions on security over the course of the day it would appear that the work JBoss are undertaking on their security strategy is completely independent of Sun with their Josso project. In addition it does strike me that JBoss have made more advances into this area than Josso has been able too to date. All in all it certainly looks like JBossSX will prove a strong contender for software security measures we choose to investigate.
This introductory session talked around the work that was ongoing, and gave an overview of the direction the team was taking with Security. I did then attend the advanced session around SSO which showed a working example, more on that in the next report.
The Security 2.0 Beta which is currently available includes SPI and an initial version of JBossSX, version 2.0 then is expected to include Identity Federation and a cleanup of SPI, at version 2.1 we should see SAML support which will make the Security module standards compliant for SSO.
The default distribution within JBoss 5.0 is apparently written to work with OpenLDAP, but this is a pluggable architecture meaning we could use JDBC ontop of our own identity store (Oracle) should we wish. Configuration changes where shown to have been made around the "login-config.xml" file.
Following a number of discussions on security over the course of the day it would appear that the work JBoss are undertaking on their security strategy is completely independent of Sun with their Josso project. In addition it does strike me that JBoss have made more advances into this area than Josso has been able too to date. All in all it certainly looks like JBossSX will prove a strong contender for software security measures we choose to investigate.
Introduction to JBoss Rules - Pete Bennett and Mark Proctor
Rules engines are a topic that we have considered a couple of times within the development team. The arguments around this have been quite fluid, making it a difficult for us to decide on a specific direction. I had hoped that I would be able to get a clearer impression from the conference on a suitable direction for Ufi and I believe I have achieved that, though not with the kind of result we would have liked.
JBoss Rules originates from the Drools technology. This is an advanced rules engine which takes rules and facts and makes assertions about them. From our perspective this means that if we write a set of business rules in DRL script, as used by the engine, we can then run these against sets of Fact objects (Hibernate objects?) to assert the results.
Rules engines, including JBossRules, look extremely appealing when considering aspects of the business such as the enrolment process and ILR. However, following discussion with the JBoss developers the fact remains that the technology is shown to work best on flat, static, data structures around which the rules are expected to change over time without any need to modify the underlying model. It is this which may make it difficult for us to realise the benefits of integrating a rules engine into something like the LASER codebase. It may still perhaps be possible for us to realise some benefits within FMI, but I suspect LASER is looking like a lost cause from this perspective unless there is some compelling reason supplied by a peripheral system.
Some interesting points about the session related to how well the tool support appears to have progressed for this technology. Plugins for Eclipse are now available for DRL, with all the usual syntax colouring, validation, etc, and DSL has evolved so that rules now have "natural language" support, making them more human readable. In addition debug and audit views were briefly shown in Eclipse, making it easy to trace activity within the engine.
JBoss Rules originates from the Drools technology. This is an advanced rules engine which takes rules and facts and makes assertions about them. From our perspective this means that if we write a set of business rules in DRL script, as used by the engine, we can then run these against sets of Fact objects (Hibernate objects?) to assert the results.
Rules engines, including JBossRules, look extremely appealing when considering aspects of the business such as the enrolment process and ILR. However, following discussion with the JBoss developers the fact remains that the technology is shown to work best on flat, static, data structures around which the rules are expected to change over time without any need to modify the underlying model. It is this which may make it difficult for us to realise the benefits of integrating a rules engine into something like the LASER codebase. It may still perhaps be possible for us to realise some benefits within FMI, but I suspect LASER is looking like a lost cause from this perspective unless there is some compelling reason supplied by a peripheral system.
Some interesting points about the session related to how well the tool support appears to have progressed for this technology. Plugins for Eclipse are now available for DRL, with all the usual syntax colouring, validation, etc, and DSL has evolved so that rules now have "natural language" support, making them more human readable. In addition debug and audit views were briefly shown in Eclipse, making it easy to trace activity within the engine.
Subscribe to:
Posts (Atom)