Isn't technology wonderful. Download a few plugins and all of a sudden your browser is an application suite.
Powered by ScribeFire.
Tuesday, November 20, 2007
Thursday, December 14, 2006
Post Conference Update
JBoss have now posted up all the presentations delivered during their sessions. A lot is changing around both Red Hat and JBoss so there's some good reading in there.
http://www.jboss.com/events/presentations
http://www.jboss.com/events/presentations
Friday, November 24, 2006
Freebies, photos and fly home
The event has proven incredibly useful. It has answered a lot of the questions I had around JBossCache and JBossRules, as well as questions I had not expected to be able to ask like JBossSX and SSO. The conference has probably raised more questions than it has answered, but then that is the nature of events like this.
It has been fascinating meeting so many of the people that work for JBoss and Red Hat, many of whom I had only previously read about. I dropped off the Ufi CD with the JBoss marketing team. Who knows if anything will come of that, but I thought it would be interesting for them at the very least.
Meeting the other delegates was also invaluable, hearing what they do, for whom and why. One or two may be in touch, let's hope so.
The conference itself was run incredibly well, and with an amazing focus on the fine detail. It was a pleasure to have been in Berlin, and the free JBoss top and bottle of German wine wasn't bad either ;)
It has been fascinating meeting so many of the people that work for JBoss and Red Hat, many of whom I had only previously read about. I dropped off the Ufi CD with the JBoss marketing team. Who knows if anything will come of that, but I thought it would be interesting for them at the very least.
Meeting the other delegates was also invaluable, hearing what they do, for whom and why. One or two may be in touch, let's hope so.
The conference itself was run incredibly well, and with an amazing focus on the fine detail. It was a pleasure to have been in Berlin, and the free JBoss top and bottle of German wine wasn't bad either ;)
Clustering and Storage / High Availability - Matthias Kranz and Jan Wildeboar
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.
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.
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.
Subscribe to:
Posts (Atom)