Naka - rock band from Belarus, leaded by actress and singer Anastasia Shpakovskaya. The band is known for its emotionally intense songs that cover a wide range of subjects including sexuality and personal tragedy.
January, 2010
Naka @ Reactor Club, Minsk
Saturday, January 30th, 2010My photos were used in the design of J:MORS official site
Saturday, January 30th, 2010Suddenly I know my photogaphs from “Navalniza” fireworks festival were widely used in the design of J:MORS official site. I wouldn’t say I’m too offended - it’s not the first time, when my concert photos are used without even leaving a link to my site or my e-mail (not talking about a fee). Moreover, I really like this band. But guys, for the future, please let me know at least 
The new form of Paranoid Programming
Wednesday, January 27th, 2010“When everybody actually is out to get you, paranoia is just good thinking.”
Woody Allen
If you go look for definition of Paranoid Programming on the web, you’ll most probably find something like: “paranoid programming is good practice in coding, the sign of professionalism, which implies considering all possible and impossible failure scenarios, and adding appropriate protection from them”. Which means patiently cultivating your fears and nurturing the paranoia, one day you’ll start producing a great output (though you should have enough budget and courage to spend so much time on building such a defensive up-front design). Whilst this old form of “programming paranoia” is peculiar to minority, new form infects almost everyone. And it’s not that positive as predecessor – it slowly drains power and confidence of masses, and pushes them to find the peace and comfort in something more stable, than coding (e.g., management 
).
So what is the modern programming paranoia all about? It’s about the fear of not being proactive enough in terms of innovative languages/approaches/platforms, and thus getting out of the programming field. Glancing over dozens of blogposts concerning personal plans for the next year, you’ll find in 99% of them a point about learning new languages (no matter which problems they address – first of all they should be trendy and have a big market share). Majority of those guys are carriers OK, I’m not arguing against learning new languages – like in human languages every new one familiarizes you with completely different culture and mentality, introduces you another type of thinking. But is it equal to be able to speak and have what to say?
Surrounded with a great arsenal of powerful toys, majority looks in their production environments for any problem that generally matches the toy’s usable area, rather than finding appropriate tools to solve concrete existing problems. People all around are highly influenced with portfolio-driven self-education (to put as much technologies to the resume as possible), because they afraid to become unemployed. Jumping into new technologies, they stop climbing the learning curve halfway up, not getting to the point and failing to reach mastership in the field.
Being over-proactive in spending time on anything new (which has a vague chance to succeed in future and gain a critical mass of followers) you shouldn’t stay ignorant of fundamental concepts of software development that are true for all languages, methods and times. Considering the real ROI of the time investments you need be very careful and selective, in order to balance your self-improvement process. Java accused of being obsolete can work for many developers for the next several years as a good bridge to new approaches (though they’re brought to market with a huge delay) – just look through the feature-list of the 7th version (also, from my point of view, Java Web Profile is a movement in the right direction – having a well defined stack of technologies will allow developer to save time on picking a suitable set of tools and start designing the system sooner).
In order to protect against paranoia for a long-term, you should be a broad specialist (which is actually highly valued in Scrum) – not just a guy, who can translate business requirements into a programming language, but the versatile developer, who are remarkable for:
- Architectural knowledge. Cutting long story short, whatever trend you follow, you need architecture and design to address complexity. You should learn from success stories, best practices and patterns. Patterns are not getting from anywhere – they’re based on huge empirical experience and sum of observations in technical fields, human society, nature, etc. The other constantly important aspect is software life-cycle management;
- Managerial knowledge. Even if you’re one of the few, who sticks to coding and don’t want to change the field for administrative work (thanks God, Peter Principle sometimes fails ), you may need to classify your managers (like in “Herding cats” by J. Hank Rainwater) and understand what air do they breath to build strong and productive relationships;
- Domain knowledge. Knowing your domain better you’re not only able to provide interpretation of business requirements into code, but also be an originator of innovations;
#####, Marie Chante Quelle Elle Telephone @ Roxy Club, Minsk
Saturday, January 23rd, 2010
RESTful orchestration with JOpera
Wednesday, January 20th, 2010Web services orchestration
In considering the concept of orchestration, we generally think about the sequence of activities (calls to the services) representing the business process. Decoupling orchestration logic from service layer provides with agility (services orthogonality, increased re-usability, and overall scalability of the system). The other orchestration purpose is in defining compositions (mashups) of services that significantly reduce complexity of the system to consumer (encapsulation of the composition’s inner organization increases its steadiness).
Enterprise integration methodology addresses orchestration with on the most complex patterns – process manager. With the benefit of centralized execution, simplified monitoring and prompt reaction on the changed situation, it adds significant complexity to design. Order of components execution (process) is described in the appropriate script. After each call to system components, control returns to the process manager that stores instances of the running processes, and knows, which next action should be executed within the process. Real-world example of the language that describes execution of activities is BPEL. BPEL is supported by a variety of process management engines (both commercial and open-source). Though it’s not an easy language to read (it’s rather machine-readable, than human-readable), majority of process management systems provide tools for visual process modeling, which make development rapid and comfortable (among them well-known TIBCO BusinessWorks, Microsoft BizTalk Server and many other)
Orchestration in REST
The composition of RESTful Web services is typically associated with so-called Web 2.0 Mashups, where this emerging technology helps to reduce the complexity and the effort involved in scraping the data out of HTML Web pages. Demand for orchestration has the very same nature as for the Big web services. The problem is that industry standard forWS orchestration, WS-BPEL, is tightly coupled with WSDL and can hardly be applied to REST. One way to work with a REST service in BPEL would be to generate WSDL/Schema that described the REST interactions and then create an adapter service or other means to communicate with the REST endpoint.
RS-world alternative to WSDL – WADL, which is claimed for repeating the mistakes of WSDL. Status and usability of WADL is still in question (it doesn’t have much followers), and it’s not supported by the current version of BPEL.
BPEL4REST is a lightweight BPEL extension, separate branch of BPEL, natively supports the composition of RESTful Web services using business processes. It declares communications with services without WADL interface.
Tools for RESTful orchestration
In spite of the fact orchestration is a trendy topic these days, there are not so many tools that can cope with REST orchestration. The engines I’ve set my choice on are:
a. Apache ODE (http://ode.apache.org/).
Pros: Apache reputation (long service life, overall solution quality); process container can be deployed to any application server and has an internal database (Derby).
Cons: supports only one orchestration language – WS-BPEL (primarily intended on integration of big services, though documentation has some good examples of declaring REST services as BPEL partners http://ode.apache.org/restful-bpel-part-ii.html ).
b. JBoss jBPM (http://www.jboss.com/products/jbpm/).
Pros: has visual process modeler; supports 3 orchestration languages (jPDL, BPEL, Pageflow); supports REST-services.
Cons: process server is the java application that was developed to work onJBoss (though there are many examples of porting Process Virtual Machine to other application servers on the Web, problems may exist, as PVM was tested only against JBoss)
c. JOpera for Eclipse (http://www.jopera.org/).
Pros: Big variety of components that can be parts of the process (not only WS or RS, but shell scripts, Java snippets, XSLT transformations, etc.); has good UI to design processes, based on Eclipse; process definitions (service compositions) deployed to JOpera server, can be accessed via REST and WS endpoints.
Cons: uses it’s own orchestration language built on top of BPEL; process server is tightly coupled with Jetty.
From me, subjectively, it’s a great joy to work with JOpera process designer. Development process wasn’t that fascinating to me for a long time;
Simple use-case
A simple use-case to demonstrate JOpera in action is caching of REST-service feedback via EhCache Server REST endpoint. The benefit of this approach is that the change is non-intrusive, and at any moment of time consumer may access both the original service and the composition (specified by the process).
Though it’s not the best example of a business process (as a matter of fact, caching has nothing to with business vertical), it can display implementation of different process tasks and elements inJOpera.
JOpera implementation
You can find basic information about JOpera installation at the home page (http://www.jopera.org/docs/help/jop.html). I’ll further concentrate on the steps required to implement the orchestration task described above. Service composition in JOpera is defined with a Process, which defines the control and data flow between the various components (the both flow are modelled visually).
3 reasons to work in a big company
Friday, January 15th, 2010
I’m getting sick of hearing over and over again how cool free-lance developers are. It’s like a cliche or the form of good breeding to talk about their courage and professional skills. I agree, there’s a certain percent of gifted self-employed consultants among them, but nearly the same percent is true with respect to the entire industry. Free-lancers is not an extraordinary caste. Moreover, the most of talented ones are finally being employed by the major players (sometimes, to hold executive positions). It’s inevitable.
My point is that you have a better chance to become an eminent specialist working in a big company. The reasons follow:
- Working for a big company you learn to think big. You can get experience of complex systems design, as big businesses have resources to build the enterprise-scale solutions. The other case is integration of ERP, CRM, ECM, etc. that normally implies using sophisticated integration patterns and adoption of SOA practices. Being a free-lancer, it is doubtful whether you will participate in 50 man/year development process or complex enterprise infrastructure roll out.
- Big companies invest money in innovations and staff education. A lot of businesses invest money in staff education which includes training camps, conferences, coaching. Employees may have some spare time every week for their own activities unrelated to their day jobs (open source projects, reading, blogging). You can certainly spend as much time for self-education as you want being self-employed, but every second you’re not working, you lose money. Secondly, the resources you can utilize. Big companies can spend huge money to buy innovative platforms and software, you can play with.
- It’s easier to keep your work/life balance. As a free-lancer your working day starts early in the morning, when you wake up, and ends, when you go to sleep (or more likely, vice verse). Interrupted with hundreds of coffee breaks, football on TV, having a shower and a million other activities you’ll do, if you stay at home. Unless you’re a time-management guru of a great willpower, you’ll fill more comfortable working in the office and having a limited business day. With a fixed number of hours per week you have less chance of burning out and forgetting how does your wife look like. It’s easier to keep up good performance over a long period of time.
After 4 years of work for a huge enterprise, I’m not going to change the game shortly as I can see benefits clearly, and most probably I will stick to big firms for the next 4 years.
P.S. First of all, thanks to everyone who’ve found time to give a feedback on my post. I had plenty of interesting conversations last several days. Here’s the short summary:
- Majority of freelancers truly think they’re extraordinary (I heard the phrase “freelance is not for everyone” 100+ times yesterday);
- Most of the people, who were against my first point, think that patterns and architecture are just for marketing giving no performance or scalability benefits (like, when you use SOA, REST, “cloud”, “grid” and other buzz-words, it’s easier to sell your ideas to CFO). Afterwards they agree that in some cases architecture is finally important, but add that majority of developers doesn’t know or misuse best practices, anyway. It’s not the argument – majority of people are sluggards (including developers, who’ve came into industry for money), who work 9-to-17, then come home, watch MTV, play computer games, etc. The thing I expected is that many of those who think the architecture is all about marketing have came from the PHP world (well-know source of really bad practices);
- Many people doesn’t take into account that freelancing implies a lot of business activities (searching for leads, turning them into opportunities, making agreements, etc.) that steal time you can spend nourishing your perfectionism, if you work for a big company;
Regular delivery with Hudson
Wednesday, January 13th, 2010Let’s imagine, you want to setup a regular build artifact delivery to your client (QA team) that deploys WAR file to the application server. In the simplest case, you’re in the same network with client, so when it receives build notification from Hudson, it can just go to the Hudson portal and download build artifacts. In practice, client often has no access to your network, and the only option is to transfer files over FTP. You’re using Hudson, and you need to find a way of triggering file transfer process when your regular build is complete.
Hudson offers high flexibility with “job” concept. You can literally make a job out of anything. In our case, we’re interested in making a job out of the script that transfers artifacts. The whole workflow to make your build deliverable over FTP is following:
1. By the moment you should have a job that builds your project. Build artifacts (WAR/EAR files to be shipped) should be archived – you can turn this option on at “Post-build Actions”;
2. Create a job that fires after your main project is built to transfers its artifacts. You can use my script for this purpose. You should pass FTP settings, Hudson home and parent project name, so that the script can find WAR artifact under Hudson, extract correct build number from Hudson configuration and post content to the FTP.
Script sends execution status to STDOUT. You can check it via Job Console in Hudson.
3. Hudson is a continuous integration tool first of all, so it primarily sends emails only if the build is broken. If you want Hudson to send e-mail notifications every time the build is successfully posted to the FTP, you need Email-ext plugin. You can change default subject and content of the notification to something more attractive and meaningful at “Editable Email Notification” section.
$BUILD_NUMBER is substituted with the current build number by Hudson dynamically.
Hudson can be used for a wide range of project lifecycle automation tasks: continuous building and testing, build artifacts delivery, monitoring, running static code analyzers. Jobs, dependency graphs and cron-like scheduling is a powerful combination for managing the build process and building extentions.
Basic toolkit for building a RESTful SOA
Tuesday, January 12th, 2010
Whilst REST is growing in popularity now more than ever, and SOA is here for more than a decade, a lot of developers (even experienced ones) are still confused with RESTful SOA definition. SOA is often considered as a system built of loosely coupled services calling each other in RPC-style, whereas SOA as a matter of fact is a fundamental methodology for building applications of different domains from reusable services (and their compositions), using orchestration and choreography principles (SCA is wonderful demo of this approach). Distinctive features of SOA are:
- Description. Service has a contract that explains consumers the rules of collaboration;
- Discovery. Ability of service (and its contract) to be found and reused;
- Orchestration and Choreography. Loose coupling/decoupling is achieved with meta-languages such as BPEL;
WS-* has a well-defined stack meeting all requirements above (and many others): WSDL for service definition, UDDI for discovery, BPEL for defining orchestration, etc. As for REST, there’s no de facto SOA toolkit. Keeping simplicity and extensibility in mind, I’m setting my choice on AtomPub and jPDL.
Atom publishing protocol
Atom publishing protocol originally created to serve Atom Syndication Standard, can be applied to a wider range of resources, and work as an application level protocol for resource publishing and discovery. AtomPub defines “collections” of resources and “workspaces” as group of collections. “Service [Document]” contains the location and capabilities of one or more Collections, grouped into Workspaces.
Small example below explains how the simple REST-service can be described with AtomPub:
<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://www.w3.org/2007/app"
xmlns:atom="http://www.w3.org/2005/Atom">
<workspace>
<atom:title>My Pictures</atom:title>
<collection
href="http://example.org/pic" >
<atom:title>Pictures</atom:title>
<accept>image/png</accept>
<accept>image/jpeg</accept>
<accept>image/gif</accept>
</collection>
</workspace>
In this example, a new resource will be created only if “accept” element with the appropriate type exists.
jPDL (jBPM)
jBPM is a platform developed by JBoss supporting business process definition languages, such as jPDL (visualized process modeling language), BPEL and Pageflow. Process languages are running under Process Virtual Machine (PVM) – another JBoss solution, process server that builds and executes process graphs in runtime. PVM is integrated with JBoss application server, although you can find demos of porting PVM to Glassfish, Weblogic and other app servers on the Internet (in the very core, PVM is nothing more than a simple Java library). Visual process modeling is done in a manner quite similar to BPEL modeling in NetBeans.
Here you can find a good demo of REST-services orchestrated with jBPM.
Aspects in UML
Saturday, January 9th, 2010Several days ago I was somewhat stuck trying to find a consisten way to display aspects (AOP) on UML diagram. Surfing the Internet I’ve managed to find two good references:
- Architectural Aspects in UML (Jon Oldevik and Oystein Haugen)
- From AOP to UML: Towards an Aspect-Oriented Architectural Modeling Approach (Mohamed M. Kande, Jorg Kienzle and Alfred Strohmeier)
According to the first, apsects can be represented with the standard stack of component diagram: component, port and information flow. The diagram below is constructed in Enterprise Architect 7.5:
