Alkpone.com

Obviously, this title is a little provocative and there is a lot of shortcut . I am myself doing architecture and software development, and I have a recurrent  rhetorical question tickling in my head; where does a particular artifact should be build.

Indeed, a common pattern in software development is too find the right boundaries, the right frontier, the right position, the right size:

• Where should I decompose my software into service,
• Where this module should be separated from another,
• Where is the frontier between meta-data (configuration, …) and data.
• Where is particular class should settle, in the GUI part, the back-end part, …

Mostly, we agree on principles, the hardest part is too put them in practice. Most the times, the remaining question is, where is the limit, the position, the size of a particular artifact (services, class, module, methods, …).

Manager has to deal with numbers, status, deadlines, very concrete facts. Architects has on different mindset; Principles, Patterns, more vague concepts even if they are often well described. Amusingly, one of this principles is to continue to code to not being too much in an ivory tour and forget all this numbers (sizing, deadlines, pragmatism, …).

Buzz word, we are all talking buzz word, SSO is one of them. What is Single Sign-On by the way?

A brief description would say that Single Sign-on is a solution to allow an end-user to use different applications using the same credentials. To give you an example, when I use modern web sites like Facebook, Dailymotion, yahoo I can use OpenID to connect to any of these applications. OpenID keeps my user information and I may connect to any of theses websites with my OpenID ID .

Another incarnation of SSO in the enterprise world is described by OASIS using SAML. Security Assertion Markup Language is an XML based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions).

(more…)

As you will probably discover, OSGI community is a very vibrant community. I will continue my articles around OSGi with some thought on the Spring flavor of OSGI as a plaform.

Spring DM Server is a product based on Spring OSGI open source project which have a goal (like always with Spring) to  encapsulate OSGI plateform to let you focus on your business code.

Then, here an insight of what Spring brings to OSGI…

(more…)

The dry principle, Don’t Repeat yourself is the second principles in my series of architecture principle I will write on.

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

I’m often talking about “meaning”, every piece of software should have only one meaning, other says responsibility. Therefore, if we have applying correctly this pattern, every times we have to made a change into our software, we don’t have to re-factor the whole stack. Exception of the cross-cutting concern (i18n, security, logging, …), modifying a module should not impact another module.

I’m not fan of code generator (someday i will write an article on that ), but for the sake of this principle, I think i would prefer having some code generation than having to copy/paste code. As long as the code generated is NEVER modified, it’s fine.

(more…)

I will write a series of article around architecture principles I follow.

Often, in the software industry, it’s hard to say “STOP, this software doesn’t need more”. We have a tendency as human to  wants more and we apply this pattern (Yes, I have said the word “pattern” ) to our software.

Therefore, following the KISS principle could be against nature. Every times I starting to design a component, writing some code, creating a information system architecture, I keep saying to myself, “do we really need this ?”, “Is that is not too much complicated ?”, “Is there something simpler to do the same job ?”…

I will become evangelist here. I see this principle as the prime principle . Before thinking of DRY or SOLID principles which are very important, as a whole, we should always keep modesty and try to add only what is really needed to our software. When i mean “add”, I mean, features, 3rd Parties libraries, source codes , commentaries…

By the way, I like this quote on the wiki link :

The principle most likely finds its origins in similar concepts, such as Occam’s razor, and Albert Einstein’s maxim that “everything should be made as simple as possible, but no simpler”.^[2] Leonardo Da Vinci’s “Simplicity is the ultimate sophistication”, or Antoine de Saint Exupéry’s “It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away”.