There are at least 2 variations of concept:

1. Client-side cloud computing, which is client-based software which is at the same time client and server to many other instances. Examples are:  Skype, BitTorrent, SETI@home.
2. Server-side cloud computing, which is automatically scalable systems like Amazon S3 or Google Apps Engine  or Salesforce which provide services on their own platform and hardware and just platforms such as Appistry for deployment on your own hardware.

We will focus on questions and concerns about server-side case.

Server-side cloud computing is when the parts of the stack where your application is running is cloned on demand if load is increasing and freed on load decrease. This is of course mostly about web and business-logic parts of the stack but also for databases. I.e. if you can automatically get more computing resources and/or more scaled database.

This is all, of course, is nothing new and could be implemented with “old” software technologies, but usually all cloud providers supply their own API optimized for cloud computing. Currently most of clouds implementations supports databases, distributed caching and transactions.

Concerns

The main concern is, of course, security, since for cloud-services providers your software is deployed on other-company’s servers. Another concern is that this architecture have issues with short high spikes loads, when it starts to scale after spike.

When to use

1. If you don’t know what load is going to be for your application;
2. When you don’t want to invest in your new hardware, clouds will be able to reuse your existing resources or you can rent the service, which will charge you only for used resources;

The anatomy of cloud computing is another good resource on this subject.

Berkeley’s view on the subject.

Let us at first remind what is inheritance (samples in Java):

public class Pet {
  public void say() { }
}

public class  Dog extends Pet {
  public void say() { System.out.println("I am a dog."); }
}

public class  Cat extends Pet {
  public void say() { System.out.println("I am a cat."); }
}

public class Test{
  public static void main(String[] args) {
    Pet pet1 = new Dog();
    Pet pet2 = new Cat();
    pet1.say();
    pet2.say();
  }
}

This  programm will output:

I am a dog.

I am a cat.

The idea is very simple: despite pet1 and pet2 are of type Pet, pet1 is pointing to object of class Dog and pet is pointing  to object of class Cat.

The common question which is usually raised is: why we don’t have just  Dog pet1 = new Dog(); and Cat pet2 = new Cat(); ? Whe do we need to access it via Pet?

Let me give you some real-world examples where do we need it:

1. Servlets. When we create a servlet we inherit base servlet class and override method  doGet() or doPost()to add our functionality to the servlet. The server (for example Tomcat) have list of our servlet classes deployed, and as soon as it gets request for our servlet it loads our class, create an object and call doGet() or doPost() on it. As soon as server have no idea what classes do we have it address object of our class via variable of type HttpServlet.

2. The similar idea was used in early versions of Struts library.

3. In .NET as well as in Java you override Exception class or one of it’s successors to create exception specific to your application. The system (Java or .NET)  knows only how to work with Exception (and RuntimeException specificly in Java) and works with all your exceptions uniformaly.

Solution is here: the-problem-of-eggs-and-a-building.pdf

Problem description

What is the way for hackers to access data of user’s account. It’s easy nowadays to let users use only cryptosecure passwords.  You can use this password meter if you want to tell them that their password is insecure and use the same code on server side to not to let user to set it. So let us assume that user’s password is already secure. But you probably want user to have a chance to reset her/his password if she/he has forgotten it. And here comes most of the issues. In my experience your security question either assume insecure answer or hard to use for users since they could have more than one correct answer for the security question. In any case this answer is far less cryptosecure then regular password, which makes it a security hole if used directly for show/change password. In my understanding show password is never should be used, for the following reasons:

1. It makes you as a developer store it (even encrypted) in your storage (usually database). This approach is VERY bad since if some hacker will get access to the database she/he will get all password for all users. It is similar issue as storing credit card in your database and could be even worse, since users tend to use the same password everywhere. Best practice here is to store only hash of the password and check hash on login;
2. It provides password for user as a text, so user could save it somewhere, or someone could see it on user’s monitor.

There are recommendations for users how to use security question in more secure way, but I doubt many follows it. Change the password will not show hacker old password but still it is easy way to get to the system.

One more huge issue is that answer for security question is stored in database as text or slightly encripted text (instead of hash). This opens up the same issue as discussed earlier.

Problem solutions

Ideally, if you can afford yourself not to use security question at all it could be a solution (although, I don’t think it is possible nowadays) . Since even the following solution will be limited by security of user’s email account.

The only you could do here is the following:

1. Use more than one security question and use them either randomly and/or more than one at the same time;
2. Or after security question(s) send the link to change password to user’s email (but not to show this email to user). In this case you will depend on security of user’s email. But if you don’t send link by email and just let user to change password this means that you providing access to user’s account secured only by secure questions which are far less cryptosecure. Alternatevely you can just show user’s hint for password, not the password itself.
3. This change password link should expire and contain some random token to check you don’t allow anyone else to use the same link to change password, and this token should expire immediately after password is changed and surely should be specific to the user (but should not be generated using any user’s information). The link itself must also not contain any information about the user;
4. Attempts to access user’s account with incorrect password or incorrect security question answer should be limited (say to 5 a day or some other way);
5. Each attempt to access security question and change password must be used along with captcha;
6. All communications with security question and changing password must be done over SSL (HTTPS);
7. Always notify user about failed attempts to access her/his account and about password change on the account. Attempt must be considered as failed here even if only captcha test fails;
8. Treat answers to security questions as alternative passwords and work with them the same way, i.e. use password input to enter an answer first time and to input it from the user on password reset process. Store only HASH of the answer not the answer itself. This is, possibly, not very convenient for the user, but will help to keep her/his secret is you database is compromised, so I would call it understandable inconvenience.

Pay attention to 5 which is usually forgotten. Captcha here, I would say playing not only it’s primary role, but also makes path to change password this way uncomfortable for user, which make her/him to use password security versus security question access. It is, I would say,  administrative way of making users not to use this way. I would also do a multi-step change password procedure.

Note on password change process

The procedure of password change should be the following:

1. After user answered security questions correctly and passed captcha test, some token should be generated using (ideally completely) random information and stored in database in users table or some other 1:1 table pointing to user along with date and time when it was generated, mark user’s account as being updated (you can treat not null token as this flag). Link to change account should be generated like this: https://yoursite.com/secure/passupdt?t=<NEWLY_GENERATED_TOKEN>   For example it could be https://yoursite.com/secure/passupdt?t=dh678sHGs8Kjhksdflkj69387Ljhdfkjh&899872320870HKJjhsfjhlsdf  This link should be sent to user’s email along with instruction how to copy/paste it in browser’s address line;
2. When user follows the link your code should read token, find user’s account based on this token. Make sure token is not expired (you can, for example, check that it was generated not earlier than 24 hours ago).  Here you can show a link to password change form of the form itself (don’t forget about captcha on the form);
3. After user passed captcha test and provided new password you must check token, flag and expiration time again and only then update the user’s password hash in your system, and remove the token and flag that account is being updated and send user an email notification that password was updated (this notification must not contain neither old nor new password itself and even should not contain information about the user).

There is a possibility that user will try to access her/his account regular way (with regular password) after step 1 or step 2. There two possibilities: if this attempt was successful or not.

• If it was successful (means that user remind her/his password and successfully login) you must immediately clear token and token flag in login action and notify user that there was an attempt to change account’s password;
• If it was not successful I don’t see anything you can do for change password process  (except regular login limitations and captcha starting form second failed attempt). Just notify user about one more failed attempt.

There is one more thing here. If user selects to change password link but he always had successful login before – this means that this activity should be considered as suspicious and user should be asked for her/his password before proceeding. If password was correct then user should be logged in and redirected to regular first-after-login page, if password was incorrect then user should be notified (by email/SMS) and only then proceed to security questions. It is clear that hackers more likely will attempt to attack security questions and not password. One other way for you to avoid it could be not to provide access to forget_password link before user try to access account regular way and fail.

Again as an alternative instead of a link with token to change a password you can send temporary password to the user, who will have to change it on first login.

I used the following articles:

http://sujitreddyg.wordpress.com/2008/01/31/blazeds-and-lcds-feature-difference/

 http://www.infoq.com/news/2008/02/granite-data-services

http://www.themidnightcoders.com/weborb/java/product_editions.shtm

http://mcoderkat.wordpress.com/2009/02/08/weborb-for-java-vs-blazeds-vs-lcds/

http://www.graniteds.org/confluence/display/DOC/1.1.+What+is+Granite+Data+Services

http://www.adobe.com/products/livecycle/dataservices/features.html

At first I would like to mention that there is difference between all patterns I mentioned, but my point is that this difference is so insignificant that it wasn’t worse dividing all these patterns.I think that Abstract Factory, Method, and Builder are all about the same: constructing objects with some method(s) and using inheritance technique to build different types (families) of object. The same is about Adapter, Bridge, Decorator, Facade, and Proxy in terms of GoF. I would reserve Proxy term for remote proxy in distributed environment, as it used now. Again for me all these patterns as presented by GoF are about intensive use of encapsulation. I personally think that existance of such amount of similar patterns is misleading.

So I had to create my own: http://www.linkedin.com/e/gis/985697

I will be happy to transfer managerial rights to enthusiasts.

Sun Certified Enterprise Architect (SCEA) for Java Platform, Enterprise Edition 5

I wonder how many people have this title?

I’d like to mention, that exam is  composed very good. It includes multiple choice exam, assignment and essay. Multiple choice is as usual, but assignment is good idea. It’ll allow examiners to see how you can handle regular architect tasks, and essay is just to check that you did you task by yourself.

If you interested in getting the title I would recommend visiting Sun’s site  and buying their Sun certified Enterprise Architect Study Guide and, of course, Core J2EE Patterns books, assuming that you already read GoF. It appeared to me that these books helps the most, despite they are quite old and do not reflect latest JEE5 features. On this features I would recommend reading Enterprise JavaBeans 3.0 (5th Edition) by Bill Burke and Richard Monson-Haefel and of course The Java EE5 Tutorial which is sometimes much more brief than Bill and Richard’s book.

The interesting thing among all of this is that Sun guys are pushing own terminology for enterprise patterns  which is not always the same as in already classical Patterns of Enterprise Application Architecture by Martin Fowler.

По традиции, тех характеристики с сайта Porsche:

• лошадок: 355;
• крутящий момент: 400 на 4600 оборотах;
• разгон до 100 км/ч: 5.4 сек;
• расход 98 бензина на 100 км: 17.9/8.4 в городе/за городом.

Ну а теперь, что есть на самом деле. Ощущение такое, что там не 355 лошадок, а 355 нахрапистых взбесившихся коньков-горбунков, которые живут своей совершенно самостоятельной жизнью. Если не переключаться в ручной режим коробки передач, то при нажатии на газ горбунки с причитающейся секундной паузой сначала нехотя, а потом вдруг резко, начинают рваться вперед так, что даже мне жутко становится. Может, порше - это машинка исключительно для ручной коробки? Или ручного режима, чтобы ездить громко и быстро? На неровностях дороги коньки ведут себя тоже совершенно непредсказуемо. Могут прыгнуть куда им захочется. Хотя общая плавность хода вполне даже себе замечательная. Мне показалась лучше, чем на BMW. Ну а о шумоизоляции в салоне можно просто забыть. Это не для Porsche. Даже если едешь по трассе на 5-й передаче, на низких оборотах звук такой, как был у моего папы на 7-ке (ВАЗ, не бимер), когда у него глушак отвалился. Серьезно. Просто дежавю. А если отключить поршевскую фирменную систему стабилизации, то ездить быстро становится просто страшно. 

Интересно также отношение порше к посадочной формуле 2+2. Если в бимере, на котором мы катались в Los Angeles-е, сзади совершенно спокойно умещались 2 пассажира, то в порше это возможно только при открытой крышке. Когда ее закрываешь, там не только невозможно сидеть не нагнувшись, но и вылезти проблематично. Если не производить хитрых махинаций с передними седлушками, они (седлушки, ес-но) просто не откинутся – крышу задевают (без шуток). Так что 2+2 по версии порше - это 2 пассажира и 2 сумочки :) Да и вообще, сегодня у любой самой дешевой мазды есть управление автомагнитолкой с руля. А конкретно, обычно можно регулировать громкость и переключать дорожки/файлы. В порше ничего такого нет. На месте этих переключалок стоят переключатели передач. Т.е. на руле только переключатели передач и бибикалка. Все, больше ничего. Типа слушайте, ребятки, моторчеГ, а не музычку.

Теперь про расход на 100. Все враки. Я ездил 80% времени по трассе, лишь слегка принажимая газок, и расход получился более 18 литров на 100. А вовсе не 8,5 и даже не 17,9! Но самый большой шок у меня вызвал прецедент, когда нам надо было остановиться, чтобы закрыть крышу, потом отъехать назад, чтобы попасть на полосу разгона, и после перестроения на дорогу коробку заклинило на 4-й передаче. Я чуть не поседел. Не помогало ничего, ни перевод в ручной режим, ни шелчки переключателя, ни переход на нейтралку. На самой же 4 по трассе ехать было очень некомфортно, т.к. оборотов было за 5000, и двигатель орал так, как будто мы не едем как все в потоке, а несемся с нереальной скоростью по автобану. Вот, кстати, 1 из преимуществ порше перед бимером это то, что крышку можно закрывать (чуть не написал “заколачивать”) на скорости до 50 км в час, а для того, чтобы проделать такой же фокус на бимере, надо полностью остановиться. Я помню, мы как-то ехали по трассе и пошел дождик, так мы проезжали мимо одного дядьки на бимере, который стоял на обочине и поднимал крышку. :)

Кстати, порше эта та машинка, про которую нельзя сказать “355 лошадок под капотом” и не из-за того, что у нее вместо лошадок бешенные горбунки, а из-за того, что под капотом у нее багажник :) Натуральный такой багажник. А движок сзади. 

Из приятных моментов в голове отложился только разгон. Все просто отдыхали далеко позади, когда я нажимал на газок посильнее. Машинка рвала так, что мало не покажется. Правда именно поэтому в остальное время приходилось очень аккуратно дозировать нажатие, иначе болид, взревев моторищем, шустро разгонялся. И при включенной системе сталибизации машинка изображала из себя трамвай. Ну и, конечно же, зависть пролетариата. Афро-американские братья ограничивались обычно просто “look at this motherfucking car!”, а какой-то белый после разглядывания машинки в шутку заявил “so beautiful car!”, “I hate you! I’ll kill you!”, обязался выйграть в лотерею такую же. :)

В общем, порше – это спортивный автомобильчик с минимумом удобств; если ездить на таком на работу – будешь приезжать уже уставшим, а вот как 2-я или 3-я машинка в гараже вполне даже ничего. Покататься с ветерком в свое удовольствие, показать пролетариату, кто есть кто :) Ну а для ежедневных поездок я бы выбрал драндулет поудобнее. Перед работой на дороге надо отдыхать! Так что у меня стресс – я думаю, что я уже совсем постарел для ежедневного порша.