Blog Xebia France

Review of the papers Xebia

The review of the papers of actuality Popular dance / weekly J2EE offered by Xebia.

Actuality editors / SSII

• Fusion GAPED / Oracle

Agility

• Marking

The corner of technology

• Maven and Eclipse: the end of the Calvary?
• Advice of Well Alex, Spring Security, to reassure his applications
• Return on enumerations with Joshua Bloch
• The architectural principles of LinkedIn

Actuality editors / SSII

Fusion GAPED / Oracle

On the July 1st, 2008, a public webcast will announce how will be included products BEA afterwards oracle Fusion Middleware.

Agility

Marking

The agile community reopens the debate on the utility of the matrices of marking of requirements in agile plans, across this thread of debate brought back by InfoQ:

• It is already necessary to differentiate the need of marking and the matrix of marking which is only a realisation.
• If one asks for marking, it is necessary to ask questions: why to make? under what form? is the added value superior to the cost?

On one of his plans, Alistair Cockburn tells that after study of the cost of the installation of a tool of marking and of its service, marking was simply taken away of the contract.

• Ron Jeffries offers to make changes and to see which tests fail to see impacts.

The agile community is in keeping and asks question: T-il has it a real need of marking? Even if it is case, the matrix of marking is a too expensive solution. The needs of marking can be covered by the practice of TDD and the use of simple tools as a system of control of versions (SVN), a tool of management of bugs / change (JIRA), a wiki, etc.

Complete debate is on Yahoo! Tech groups Requirement Traceability Matrix and Agile Testing.

The corner of technology

Maven and Eclipse: the end of the Calvary?

Who has not ever grumbled regarding integration Maven in Eclipse?

And well a page is turning, in the Maven Community News of May, Arnaud heir announces the entrance of PLUGINS IAM (Q4E) AND M2E (M2Eclipse) in the incubator Eclipse.

Until now, alone Ant had a fine integration with Eclipse. Without participation nor communication hurries up of the community Eclipse, PLUGINS Maven was led to perform soldering by their own means. What indeed explains the relating non-reliability of the existent PLUGINS.

For its release next, Eclipse finally changed sides, restarting competition with renewed vigour between two PLUGINS (cf SCOPES IAM and M2E). We can hope for the official exit of a plugin of quality in close future.

Advice of Well Alex, Spring Security, to reassure his applications

Well Alex, Spring Security (ex Acegi Security), introduced JavaOne 2008 in addressing tomorrow' s security requirements in enterprise applications stakes of security of applications popular dance. We will keep his pipes for the applications of firm:

• Use a felt framework of security rather than to rewrite his
• To begin simply and to add incr mentalement complexity
• Anticipate the needs of recording of the users
• Plan the federation of identity, particularly with [1]
• For internal applications, consider NTLM and CASE
• Use the techniques of Captcha to limit attacks by (BACK)
• Prefer permissions on methods Popular dance to permissions web on URL
• To describe the m tas-data of permission with annotations is simple and quick
• Consider with most close attention the security of the objects of domain
• Prefer BASIC authentication on HTTPS for correlations REST
• Use the wealth of standards Web Security (WSS) services for independent exchanges SOAP of the transport (HTTP, JMS, etc)

[1] They will remember reproaches however currently made to OpenID (cf. The problem with OpenID, The Identity Corner)

Return on enumerations with Joshua Bloch

Joshua Bloch, the author of Real Popular dance, reminded JavaOne 2008 in More Effective Popular dance the large field of application of listing. We will keep:

• Do not use ordinal to carry data of whole type; use a field int
• Do not use bit fields; use one EnumSet
• Do not use ordinal for to index pictures; use EnumMap
• Do not use readResolve for a serializable singleton; use one enum
• Simulate the extensibility of listing with interfaces

We will not come back on debate  listing is a pattern bad because they prevent extensibility  . If this reproach is sometimes justified, we will keep that Joshua Bloch offers the pattern of interfaces to control this risk and that it was never also easy to refactorer and to re-compile an application. As for the request of evolution  add a third sex besides Gender and Gender.FEMALE , 

The architectural principles of LinkedIn

Last week, we took back an article in the review of the papers on the architectural main principles of eBay.
During JavaOne 2008, it is the Community site LinkedIn which came to light.
We take back here the main lines of 2 following presentations: LinkedIn Communication Architecture and LinkedIn: has social network professional

Let us begin with some figures. LinkedIn it is:

• 22 million members
• 4 + million unique visitors a month
• 40 million pages seen a day
• 2 million electronic mails sent a day

Physical architecture

• 100 % Popular dance
• Tomcat and Jetty, on Solaris
• Oracle and MYSQL, questioned directly in JDBC (not of mapping Object / Relational)
• ActiveMQ as system of messaging
• Lucene as base of research function
• Spring for communication between elements

Intensive practice of Agility

• Accent extremely carried on the test
• Cycles of short developments (2 - 4 weeks)
• Cutting up of developments in small units
• Not enough definite meetings, use of meeting of type 'stand-up'
• More than 6500 unit tests and 500 tests of IHM
• Integration goes on with Hudson, nightly builds
• Use of Mock to reduce the redundancy of the tests of integration
• Constant Refactoring

Orientated architecture service

• The present webApp graphic interface to the users but leans on a service layer.
• Every Service uses its own 'partition ' of database (partitionnement 'functional ')
• Use of retorts of DB, and distribution of updates, from the master, by the use of a bus of events
• Massive use of asynchronous fluxes
• D coupler at the farthest correlations between service, what allows to reduce inter dependency of code.
• This architecture is scalable service by service

A server is devoted to the representation of the whole network LinkedIn (The Cloud)

• Representation of the totality of the tree in memory (22 million knots, 140 million links)
• The tree uses 12 Go of RAM on 40 authorities
• The reconstruction of network from scratch takes more than 8 hours
• The tree is real-time updated by the bus of events
• This choice follows directly from the functional difficulty in partionner the tree

Main principles of scaling (the underlined points are the same that those displayed by eBay)

• Partionner by functional domains
• The partitionnement makes referential integrity difficult cross-country running domain
• The complete integrity of data does not exist
• Large-scale, the material costs become a problem to be taken into account
• Spammers and thieves of data are a problem
• Use the mask, even if it has a limited effectiveness
• Use asynchronous treatments
• The tasks of analysis and of strengthening of report must be taken into account from initial design
• To envisage cases of failure of the system, they will not miss to occur
• Not under estimate not the growth of your site

Why to prefer Popular dance

• With more d 1 million lines of code, Popular dance allows:
  1. to refactorer with complete confidence
  2. To sail easily in the source code
  3. To support about twenty branches at the same time, the compiler helping to accomplish fusion
• It is easy to make go up the team in power:
  1. More than 8 teams, 50 engineers, in constant increase
  2. It is easy to find developers talented Popular dance
• The Popular dance community is big and active

Conclusion

As it is possible to see him, the architecture of LinkedIn has many common points with that of eBay, especially when they are nearly interested in concepts which allow these two sites to give a competitive service to millions of subscribers. These architectural main principles appear therefore inevitable for any application aiming at supporting a heavy load.