Spring released its latest major release: 3.0.0.
The new features are there : http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/new-in-3.html.
I have been quickly trough the list, at this stage it is hard for me to say that it is going to change my life as 2.xx did. But for sure I will spend some time looking at these new features.
Showing posts with label spring. Show all posts
Showing posts with label spring. Show all posts
Thursday, December 17, 2009
Monday, November 23, 2009
Two busy weeks - back from Milan - Number portability - the Belgium case
Last Monday, I did a one day trip to Milan to give a class about our middleware for number portability. A big piece of Java work that would have very much benefited of Spring.
In fact I solved the beans configuration exactly the reversed way Spring does. Basically I stored all the configuration stuff in a single object for each sub process and every component take what's relevant for its job.
I know this make all this code dependent on this big fat object. I think some people call that a white board design. I agree this lack elegance and hinder re-usability. On the other side it simplified very much configuration and because objects share the config info it is naturally consistent. The same object also implemented a factory pattern, creating and initializing most of the objects (a better part of my design).
Most of us keep looking forward, but I think checking what happened backwards brings also some values.
There is a lot to say on this project not only on the Java side but also project wise.
Number portability (moving from one operator to another but keeping your number) has been implemented in most European countries (because of European market regulation). Yet each country had the freedom to implement it its own way. This has been for me an opportunity to work many times ( for Belgium, Luxembourg, Spain, Portugal, Italy, Germany, Hungary Finland, Latvia, Nederlands, Lithuania, Estonia, Croatia, Hungary ) on similar but different projects.
Typically, number portability is solved by a central database that lists those numbers that have been ported to another operator. An administrative process - kind of work flow - has to be implemented, usually with time constraints. Once porting is agreed between the donor and the receiving operators, a technical phase propagates the porting information to all operators. The net result being that all operators own a copy of the central database that feeds the operators switches (usually trough what is called an Intelligent Network platform).
Belgium was the first process I developed. The central database project was outsourced to a contractor - a very big, well known international software house.
The entire process was driven by a committee piloting the contractor. That generated what committees like to get: papers (probably also a lot of meetings and a high volume of coffee breaks).
The full documentation filled an entire CD (for comparison I received the Spain technical documentation - a single file format description - on one page).
Technically this was my first exposure to Web services (more or less 6-7 years ago). That part was great. However the web services was described as an XML schema - no WSDL. So I had to use an XML parser,code and decode the messages.
The rest of the project was 'nuts' and was a school case on what not to do.
The committee-contractor tandem generated a lengthy and mostly absurd acceptance process, so we had to simulate business transactions of all kinds in an absurd repetitive fashion. Testing and preparing acceptance reports took finally 3-4 times more resources than developing the Web services.
More funny was the total absence of service oriented attitude of the contractor. The idea of giving an easy test platform, a reference implementation, or any basic tools (e.g: raw messages) for developers was out of their mind. Just for one reason. Not only they got the contract for the central database, they also expected to take the business of all the connecting operators. So the motivation to help anybody was naturally extremely low.
They also provided a web based application. They used Java and the most modern computers stuff at that time - multi-processors Sun servers, clusters, Oracle, Nokia Checkpoint appliances, load-balancers etc This was very professional. Unfortunately the application quickly turned out to be a pig. Users started to complain from availability, performance , error messages, failling transactions etc.
In my opinion, this was due to the inexperience of the programming staff and finally a very poor design.
A constant problem of big consulting companies is that they send their senior people to win a deal and send junior staff to implement it. As the amount of problems became important, their support staff could not follow anymore. They entered into crisis management by the book - thus delivering an help-desk procedure that requested a complete network description just for asking a password... Of course, this exasperated their users more than it solved problems.
I never attended these comittee meetings. The specs were done when I started the project for my customer.Why have they decided to build their on messaging infrastructure on top of relational database using Soap. I don't know. However I saw later similar designs and it seems they copied a system developed in the UK.
In a search to create additional work, they decided that a VPN was not enough. SSL certificates were used between all parties. Good. Obviously they created their own certificate request process with conventions about what to put in each field of the certificate - this was described in a 20+ pages document (all other countries I saw after, simply ask to exchange public certificates between the operator and the central database - final point). In fact their policy and certificate distribution could have been meaningful if the transaction had to be secured end to end - operator to operator - which they did not.
In the line with their policy to create work, the certificates were issued for a single year, this created a permanent state of maintenance multiplied by two (test and production had to be renewed). The funniest thing was when I setup our messages reception point. The only way I could setup the server to get messages was turning off client certificate authentication! Half of their stuff did not work because they were not providing a complete certificate chain. When I discussed that with the contractor security 'expert', I could measure a long silence that finished by 'what's important is that it works now'. Indeed but as far security is concerned...
A few years later, the outsourcing contract expired. The operators committee took the decision to swap the contractor and the entire application! So the new contractor re-implemented the entire system ! Their implementation had to be identical for the Soap transaction and they decided to keep the SSL security system, unchanged...
In fact I solved the beans configuration exactly the reversed way Spring does. Basically I stored all the configuration stuff in a single object for each sub process and every component take what's relevant for its job.
I know this make all this code dependent on this big fat object. I think some people call that a white board design. I agree this lack elegance and hinder re-usability. On the other side it simplified very much configuration and because objects share the config info it is naturally consistent. The same object also implemented a factory pattern, creating and initializing most of the objects (a better part of my design).
Most of us keep looking forward, but I think checking what happened backwards brings also some values.
There is a lot to say on this project not only on the Java side but also project wise.
Number portability (moving from one operator to another but keeping your number) has been implemented in most European countries (because of European market regulation). Yet each country had the freedom to implement it its own way. This has been for me an opportunity to work many times ( for Belgium, Luxembourg, Spain, Portugal, Italy, Germany, Hungary Finland, Latvia, Nederlands, Lithuania, Estonia, Croatia, Hungary ) on similar but different projects.
Typically, number portability is solved by a central database that lists those numbers that have been ported to another operator. An administrative process - kind of work flow - has to be implemented, usually with time constraints. Once porting is agreed between the donor and the receiving operators, a technical phase propagates the porting information to all operators. The net result being that all operators own a copy of the central database that feeds the operators switches (usually trough what is called an Intelligent Network platform).
Belgium was the first process I developed. The central database project was outsourced to a contractor - a very big, well known international software house.
The entire process was driven by a committee piloting the contractor. That generated what committees like to get: papers (probably also a lot of meetings and a high volume of coffee breaks).
The full documentation filled an entire CD (for comparison I received the Spain technical documentation - a single file format description - on one page).
Technically this was my first exposure to Web services (more or less 6-7 years ago). That part was great. However the web services was described as an XML schema - no WSDL. So I had to use an XML parser,code and decode the messages.
The rest of the project was 'nuts' and was a school case on what not to do.
The committee-contractor tandem generated a lengthy and mostly absurd acceptance process, so we had to simulate business transactions of all kinds in an absurd repetitive fashion. Testing and preparing acceptance reports took finally 3-4 times more resources than developing the Web services.
More funny was the total absence of service oriented attitude of the contractor. The idea of giving an easy test platform, a reference implementation, or any basic tools (e.g: raw messages) for developers was out of their mind. Just for one reason. Not only they got the contract for the central database, they also expected to take the business of all the connecting operators. So the motivation to help anybody was naturally extremely low.
They also provided a web based application. They used Java and the most modern computers stuff at that time - multi-processors Sun servers, clusters, Oracle, Nokia Checkpoint appliances, load-balancers etc This was very professional. Unfortunately the application quickly turned out to be a pig. Users started to complain from availability, performance , error messages, failling transactions etc.
In my opinion, this was due to the inexperience of the programming staff and finally a very poor design.
A constant problem of big consulting companies is that they send their senior people to win a deal and send junior staff to implement it. As the amount of problems became important, their support staff could not follow anymore. They entered into crisis management by the book - thus delivering an help-desk procedure that requested a complete network description just for asking a password... Of course, this exasperated their users more than it solved problems.
I never attended these comittee meetings. The specs were done when I started the project for my customer.Why have they decided to build their on messaging infrastructure on top of relational database using Soap. I don't know. However I saw later similar designs and it seems they copied a system developed in the UK.
In a search to create additional work, they decided that a VPN was not enough. SSL certificates were used between all parties. Good. Obviously they created their own certificate request process with conventions about what to put in each field of the certificate - this was described in a 20+ pages document (all other countries I saw after, simply ask to exchange public certificates between the operator and the central database - final point). In fact their policy and certificate distribution could have been meaningful if the transaction had to be secured end to end - operator to operator - which they did not.
In the line with their policy to create work, the certificates were issued for a single year, this created a permanent state of maintenance multiplied by two (test and production had to be renewed). The funniest thing was when I setup our messages reception point. The only way I could setup the server to get messages was turning off client certificate authentication! Half of their stuff did not work because they were not providing a complete certificate chain. When I discussed that with the contractor security 'expert', I could measure a long silence that finished by 'what's important is that it works now'. Indeed but as far security is concerned...
A few years later, the outsourcing contract expired. The operators committee took the decision to swap the contractor and the entire application! So the new contractor re-implemented the entire system ! Their implementation had to be identical for the Soap transaction and they decided to keep the SSL security system, unchanged...
Tuesday, August 11, 2009
VMWARE acquired SpringSource
Strange but confirmed. VMWARE acquires SpringSource... I am on my hass !
The only understandable synergy at this stage is the Hyperic applications monitoring (that SpringSource acquired recently). VMWARE is eager to be a key player in vitual infrastructure - so called cloud. That makes sense. But what will do VMWARE with all this Java stuff?
I am a bit concerned about the future of the Spring container (and Groovy and Grails).
http://www.vmware.com/company/news/releases/springsource.html
The only understandable synergy at this stage is the Hyperic applications monitoring (that SpringSource acquired recently). VMWARE is eager to be a key player in vitual infrastructure - so called cloud. That makes sense. But what will do VMWARE with all this Java stuff?
I am a bit concerned about the future of the Spring container (and Groovy and Grails).
http://www.vmware.com/company/news/releases/springsource.html
Thursday, June 04, 2009
Spring for Python - Yes they can !
I could not believe my eyes... SpringSource did it again... translating parts of its framework to Python -- including the IOC ! Ok I am convinced, I will give a serious look at Python.
By the way, my OpenERP on my Ubuntu is fine. I will go through Python tutorial (I bought already two book in french, but I found them not that good) and build a first development environnment.
By the way, my OpenERP on my Ubuntu is fine. I will go through Python tutorial (I bought already two book in french, but I found them not that good) and build a first development environnment.
Monday, May 11, 2009
Netbeans & Spring - refactoring not easy as it should be
Well, may be you think it is caused by poor design... But I wanted to change the way a few objects were named modify the packaging structure in a soon to be released application. Refactoring with Netbeans is usually easy as the IDE changes properly references for you. Well it does in the Java code but not in the Spring XML definition !
Too bad and now hours of checking ahead !
Too bad and now hours of checking ahead !
Wednesday, May 06, 2009
SpringSource support pricing - nothing free - like free lunch?
Interesting article about SpringSource support pricing http://java.dzone.com/articles/the-cost-springsource-enterpri
Obviously, the company has to get revenues from something but it is good to remember that some free stuff can finally cost more than their commercial equivalent products.
Also some comments of the article about the source repository and the possibility to get fixes without a support contract are relatively pertinent.
I say relatively because my experience is that even with subscription and support contracts, small companies have difficulties to get their problem recognized by some vendors.
My feeling however is that SpringSource plays the classical commercial Java game - meaning the pricing is not clearly displayed and replaced by "contact sales".
Again this is complicated for small companies and makes comparison very difficult. So watch before to take a technical decision and don't forget that the relation with the vendor also matters.
Obviously, the company has to get revenues from something but it is good to remember that some free stuff can finally cost more than their commercial equivalent products.
Also some comments of the article about the source repository and the possibility to get fixes without a support contract are relatively pertinent.
I say relatively because my experience is that even with subscription and support contracts, small companies have difficulties to get their problem recognized by some vendors.
My feeling however is that SpringSource plays the classical commercial Java game - meaning the pricing is not clearly displayed and replaced by "contact sales".
Again this is complicated for small companies and makes comparison very difficult. So watch before to take a technical decision and don't forget that the relation with the vendor also matters.
Tuesday, May 05, 2009
SpringSource acquires Hyperic
SpringSource acquires hyperic. It is astonishing to see how well SpringSource played these last two years. While integrating various other products and frameworks SpringSource mastered the art of making a consistent Java alternative enterprise offering. I spent little time on monitoring and scaling, but I think it make sense.
SpringSource is kind of safest (specially considering the uncertain Oracle-SUN strategy), efficient way of doing lean good Java apps. I think its business model should be studied in depth. All their products are pure open source. Great documentation is provided (good affordable documentation is a key for community acceptance). So training, conference and expertise is their single financing at this stage. It is funny to see how SUN could never build a decent software service stream of revenues while alternate vendors did...
I hope they wille give it a shot in the RIA dance. Or do we have to consider that BlazeDS (Flex intergation) is their way to RIA ?
SpringSource is kind of safest (specially considering the uncertain Oracle-SUN strategy), efficient way of doing lean good Java apps. I think its business model should be studied in depth. All their products are pure open source. Great documentation is provided (good affordable documentation is a key for community acceptance). So training, conference and expertise is their single financing at this stage. It is funny to see how SUN could never build a decent software service stream of revenues while alternate vendors did...
I hope they wille give it a shot in the RIA dance. Or do we have to consider that BlazeDS (Flex intergation) is their way to RIA ?
Friday, May 01, 2009
ROO ? From SpringSource
One more stuff on my 'to evaluate list'. I must say that the Spring lightweight container is one of the most pleasant encounter I did with Java stuff these last two years.
My statement : right to the point. Good design, good documentation absolutely non obstructive, this makes programmers productive, designs elegant and solutions flexible...
This is the perfect example of how much innovation in the Java landscape is powered more by third parties than by the official JCP/JSR and owner of the language (SUN - now Oracle).
SpringSource also acquired the company behind Groovy and Grails. Nice language and probably easier to learn than Ruby On Rails (for a Java programmer) and with I think a much better (in fact perfect) integration with Java.
Well it seems that SpringSource continues its walk to ease programmer productivity with a project called 'ROO'. The name is not definitive it seems to be centered around Maven and provide command lines wizard to assemble application. Release is expected for July 2009. Wait and see.
My statement : right to the point. Good design, good documentation absolutely non obstructive, this makes programmers productive, designs elegant and solutions flexible...
This is the perfect example of how much innovation in the Java landscape is powered more by third parties than by the official JCP/JSR and owner of the language (SUN - now Oracle).
SpringSource also acquired the company behind Groovy and Grails. Nice language and probably easier to learn than Ruby On Rails (for a Java programmer) and with I think a much better (in fact perfect) integration with Java.
Well it seems that SpringSource continues its walk to ease programmer productivity with a project called 'ROO'. The name is not definitive it seems to be centered around Maven and provide command lines wizard to assemble application. Release is expected for July 2009. Wait and see.
Subscribe to:
Posts (Atom)