In comparison to other Sun Certifications, this one is not focusing on a test of how good you learn the API of a JEE Specification. The theory questions aim to test a general understanding of the JEE technologies, their usage areas and their purpose. There are also some questions testing your understanding of the advantages and caveats of JEE Stack. In general it was not very difficult – I spend several days on preparation and got my 89% (you only need 57% to pass).

The assignment part is pretty interesting. You have to submit a document describing the architecture of the system under development, which contains a set of UML 2 diagrams (class, sequence, deployment, use case). This part is a good excersize for any architect. In addition, you have to identify the main three threats and describe mitigation strategies for them. I found this part interesting, since I noticed that I’m usually not doing it on such level of detail, but judge about the risks based on my own experience. The second and the third parts are evaluated together. You can get at most 160 points and need 114 to pass (71%). I spend almost a week every evening for creation of the assignment and was happy of getting 140 point (87%).

You are among the elite 1% of certified Java professionals who have gone on to achieve the Java Enterprise Architect certification.”

That’s really funny.

At any rate, I enjoyed the preparation time, the exams and I’m glad about the result.

Bei der Einführung von Serviceorientierten Architekturen (SOAs) ist Wiederverwendung nur eines von vielen Zielen, die miteinander um Priorität konkurrieren. Wiederverwendung erreicht man also keinesfalls allein durch die Wahl einer entsprechenden technischen Platt form, sondern nur in Verbindung mit vielen Entscheidungen auf organisatorischer Ebene. In diesem Artikel wollen wir die aus unseren Erfahrungen wichtigsten Vorgehensweisen und Erfolgsfaktoren beschreiben, die bei der Erreichung einer hohen Wiederverwendung innerhalb einer SOA kritisch oder hilfreich sind.

The main idea of the BlackBeltFactory is to create an e-learning platform around computer engineering skills. The site provides so-called courses and workshops: real educational content to different subjects. In order to access the course material, you not only need the account at the site, but should also have a coach, helping you to consume the material. If you get one (I’ll tell you later how this works), you can study the content and solve excersises. On any questions you can contact the coach who is intended to help you, usually via skype or email.

Once you are done with studying – you should test yourself by registering to an exam. An exam is a set of online multiple-choice questions. In order to pass exams, you also require some contribution points. You get contribution points for any kind of community activity: connect you status update with twitter, edit questions, post comments, translate course materials – everything you do for the site and community gives you contribution points. In addition, you can create groups and invite people into them.

Every passed exam gives you some knowlegde points. For a number of knowlegde points earned, you get a belt. Belts have different colors: white, yellow, orange, green, blue, brown and finally black. For the black belt you not only need enough knowlegde points, but also have to be a successful coach for two other students, which means that they have to pass the exams and give you feedback.

After you get a blackbelt, you may offer coaching for money. You give 20$ + 15% of the coaching proce to BlackBeltFactory, but I suppose this is fair enough. The site gives you a possibility to create coaching offers (free or paid) and manage the students, who are looking for the coaches – a real e-learning marketplace.

I had an idea to get the black belt by passing exams of subject I think I’m expert in, without taking all the courses. It turned out, that the exam questions are pretty good – you easily pass the subject you are good in, but you ultimatively fail in subjects where you have knowledge gaps. Another problem you face is the lack of contribution points. For this purpose, there exist a so-called belt track, a series of exams in which passing an exam enables the next one without spending contribution points. The exams are predefined but cover basic Java, OO, XML and Web technolgoies, so I could use the track to achieve the blackbelt quickly.

I like the site because I have the possibility to test my knowledge. The tests are not trivial, but reveales subjects you should deepen. On the other hand the site lives from the contributions. You can do anything – from commenting bad exam question to designing new questions, exams, courses – whatever. I also liked the education part, where you have to teach a Java fundamental course for free. That’s not trivial if a person you teach really starts from scratch, but very interesting and challenging. I also like the fact that you can do a lot without paying money – very good business model.

Sometimes, the site shows strange behaviour, but you can ever finish your work. At some places the site seems to be not following its own styleguide and look&feel, but these are details. I’m a big fan of BlackBeltFactory.

Martin told about the OSGi technology and the usage of it in big projects. He advertised the OSGi module system but also pointed on some pitfalls during design of the architecture. I was a little dissapointed, since it was a kind of entry-level talk, and its main emphasis was to recollect the importance of the service-oriented principle during system design. He pointed out the importance of loosly coupling and implicit dependency which foster maintainability of the system for many years. In the same time the fulfillment ofsuch architectural principles does not come for free.

Jan Köhnlein made a talk on DSLs in general and Xtext 2.0 in particular. The guys from itemis did a nice job in developing Xbase, a new language which can be used inside of the user DSL. For me, it is a huge step towards ubiquitous application of DSLs in software projects. Xbase give the ability to specify behaviour inside of DSLs. It is statically typed, compiles to Java, supports closures and type inference, operator overloading, etc.. – many nice features to use a little more functional programming language features in your DSL. Especially the ability to mix Java Types with Types defined in your DSL in combination with higher-order functions seems very powerfull to me.

Finally, Ralf Ebert made a very decent presentation on Git – the popular distributed versioning system. I am a big fan of Git and use it for many things i develop and saw many different presentation on those – but Ralf’s was the best one. He explained very plastically the difference in usage of Git to other versioning systems like SVN or CVS. He also showed a nice demo by showing some interesting branching and merging scenarios by switching between two users (Alice and Bob) on his machine and developing a simple web application. It was fast, precise and understandable – very nice talk.

The next Nordic Coding is planned for the August 19th, 2011.

More pictures in my FlickR set…

• SANY – Syntax Analyser for TLA+ specifications
• TLC – A modelchecker / simulator for TLA+ specifications
• TLATeX – LaTeX typesetter for TLA+

The PCal Translator is not covered in this post and will be introduced in a separate post, together with PCal language.

SANY

SANY is a syntax analyser for the TLA+ language. The purpose of it is to check the syntax of the specifications (including some static semantics) and provide the errors to the user. As all of the TLA+ Tools currently available, SANY is a command line tool and reports the errors back to the console. In fact SANY is a front-end of the compiler (lexer, parser, semantic analyser). In order to invoke it call:

java -cp %TLA_CLASSPATH% tla2sany.SANY fowler.tla

SANY is currently the only official way to find out, if the specification complies to the rules of the TLA+ language. It is absolutely a non-trivial program, basically because of the complexity of the TLA+ grammar. Especially, the parts responsible for precedence-checking and level-checking are use complex algorithms.

TLATeX

As noticed by Peter, the language has a special notation, which could appear cryptic to someone who see them for the first time. The reason for this is pretty simple: TLA+ is a mathematical language and the ASCII version TLA+ is very close to LaTeX notation of the corresponding mathematical symbols. Everyone, who is aware of LaTeX can read and write TLA+ easily. For others, the ASCII specification can be translated into a TeX file and rendered to a DVI, PS or PDF. A piece of specification of the secret compartment ( download full TLA file), looks as follows rendered as PDF ( download as PDF).

The question of WYSIWYG editor support involves not only rendering of the symbols (that is the easiest part), but the input of these symbols by the user. Therefor, the ASCII version of TLA (we could also speak about ASCII encoding), which uses at least in certain areas know LaTeX-like encoding is a convenient way for editing specs. There are attempts to create WYSIWYG formula editors, which work pretty good, but the these have to be used with a mouse and the input speed is not comparable with the typing plain LaTeX.

The usage of TLATeX is simple. After the installation of TLA Tools, the TLATeX is invoked from the command line:

java -cp %TLA_CLASSPATH% tla2tex.TLA -shade fowler.tla

The tool produces a .tex file which can be included in the existing document. It also can be rendered directly if LaTeX is installed on machine.

TLC

TLC is a model checker for TLA+ specifications. It’s main purpose is to find bugs in specifications. For this purpose it creates the state-space described in the specification and checks the properties (safety and liveness). In contrast to SANY which is responsible for syntax and static semantics check TLC is checking the dynamic semantics of the specification. At this point I only want to mention, how TLC is invoked. I’ll cover some advanced TLC topics in the later posts:

java -cp %TLA_CLASSPATH% tlc2.TLC fowler.tla

In addition to the TLA file, containing the specification itself, TLC requires a CFG file, which describes the model, that has to be checked. This fact appears unusual to the TLA beginners, but is easy to clarify. The specification of the system is a description of systems behavior. To a given behavior, several models can be constructed. In addition, specifications can be combined resulting in bigger specifications. In the specification, there are no real differencies between actions: (Init, TypeInv, CloseDoor or Spec). Thus, the user has to specify which of these actions are actulally the parts to check.

(* ************************************ *)
(* Controller of the secret compartment *)
(* of Mrs. H, who loves secrets!        *)
(* Following the example of M. Fowler,  *)
(* which can be found at:               *)
(* http://martinfowler.com/             *)
(* ************************************ *)
------------- MODULE fowler --------------
(* ************************************ *)
(* Variables                            *)
(* ************************************ *)
VARIABLE
  state, \* the state for display, only
         \* to be compliant with  Fowler
  light, \* state of the light
  draw,  \* state of the draw
  panel, \* state of the secret panel
  door   \* state of the entry door

TypeInv ==
(* ************************************ *)
(* Type invariance                      *)
(* ************************************ *)
  /\ state \in { "idle",
                 "active",
                 "waitingForDraw",
                 "waitingForLight",
                 "unlockedPanel" }
  /\ light \in { "on", "off" }
  /\ draw \in { "opened", "closed" }
  /\ door \in { "locked", "unlocked"}
  /\ panel \in { "locked", "unlocked" }

Init ==
(* ************************************ *)
(* Initial state                        *)
(* ************************************ *)
  /\ state = "idle"
  /\ light = "off"
  /\ draw  = "closed"
  /\ door  = "unlocked"
  /\ panel = "locked"
------------------------------------------
(* ************************************ *)
(* Actions                              *)
(* Note that the state variable is not  *)
(* used for the determination of the    *)
(* actual state, but only for display.  *)
(* This shows that this variable        *)
(* is not required in TLA+              *)
(* ************************************ *)

CloseDoor ==
(* ************************************ *)
(* Closes the door, to activate         *)
(* ************************************ *)
  /\ door = "unlocked"
  /\ door' = "locked"
  /\ state' = "active"
  /\ UNCHANGED << panel, light, draw >>

LightOn ==
(* ************************************ *)
(* Switch on the light, if the draw is  *)
(* opened, this opens the secret panel  *)
(* ************************************ *)
  /\ light = "off"
  /\ light' = "on"
  /\ IF draw = "opened" THEN
       /\ state' = "unlockedPanel"
	   /\ panel' = "unlocked"
	   /\ door' = "locked"
	 ELSE
	   /\ state' = "waitingForDraw"
	   /\ UNCHANGED << panel, door >>
  /\ UNCHANGED << draw >>

OpenDraw ==
(* ************************************ *)
(* Open the draw, if the light is on,   *)
(* this opens the secret panel          *)
(* ************************************ *)
  /\ draw = "closed"
  /\ draw' = "opened"
  /\ IF light = "on" THEN
       /\ state' = "unlockedPanel"
	   /\ panel' = "unlocked"
	   /\ door' = "locked"
	 ELSE
	   /\ state' = "waitingForLight"
	   /\ UNCHANGED << panel, door >>
  /\ UNCHANGED << light >>

ClosePanel ==
(* ************************************ *)
(* Closes the secret panel and move the *)
(* system to initial state              *)
(* ************************************ *)
  /\ panel = "unlocked"
  /\ panel' = "locked"
  /\ light' = "off"
  /\ draw' = "closed"
  /\ door' = "unlocked"
  /\ state' = "idle"
------------------------------------------
Next ==
(* ************************************ *)
(* All possible actions                 *)
(* ***********************************  *)
  \/ CloseDoor
  \/ LightOn
  \/ OpenDraw
  \/ ClosePanel

Spec == Init /\ [][Next]_<< panel, light,
  draw, door, state >>

THEOREM Spec => []TypeInv

Inv ==
(* ************************************ *)
(* The panel is never unlocked          *)
(* by opened door                       *)
(* ************************************ *)
  \/ panel = "unlocked" => door = "locked"
  \/ door = "unlocked" => panel = "locked"
==========================================

In order to run a model checker, the configuration file fowler.cfg needs to be created. It says which part of the model is the specification, and what should be checked. In the example above, the specification action is called Spec and states, that if the Init action is executed, the Next action can always be executed by allowing stuttering steps by changing values of the variables panel, light, draw, door and state. The actual property we want to check is the fact, that the compartment is really safe, which means that the secret panel can be unlocked if and only if the door is closed. This is stated in the property Inv which has to be an invariant property of the system.

SPECIFICATION   Spec
INVARIANT       Inv

Running TLC on this specification, with configuration file provided above produced the following output:

TLC2 Version 2.01 of February 23, 2008
Model-checking
Parsing file fowler.tla
Semantic processing of module fowler
Finished computing initial states: 1 distinct state generated.
Model checking completed. No error has been found.
Estimates of the probability that TLC did not check all reachable states
because two distinct states had the same fingerprint:
calculated (optimistic):  2.927345865710862E-18
based on the actual fingerprints:  1.2569902552401487E-14
15 states generated, 9 distinct states found, 0 states left on queue.
The depth of the complete state graph search is 3.

This means, that it reached all states with very high probability and checked in every state the required property.
The compartment of Martin is safe! Modelchecked by TLC.