mondora is expanding with a new office

View Larger Map
The just born division of Software Development of mondora, is based in a new office based in Valtellina. Valtellina is a green valley where air is still breathable, life-style is still for humans, where you can see mountains, cows and other things that relax.

Our aims are to develop and maintain software with a fresh mindset; we're focusing on a culture on developing software different from the others where programming languages are a way to build software and are not a prerogative of each individual. We will focused in delivery high value added software there for a specific target: corporates that wants to produce revenue with low cost solution.

Office is now hosting 4 developers and the executive board, when present.

Office location is:
mondora.com
via Vanoni 59/A
Morbegno
Sondrio (Italy)

BEYOND SOA IS SPOA

IT market in general - and software vendors in particular – have emphasized SOA paradigm (Service Oriented Architecture) being the silver bullet for actual and future software developments. Recent studies (e.g.: “SOA and BPM for Enterprise Applications: A Dose of Reality”, AMR Research Inc, May 2007), show how SOA is perceived/applied within enterprises, and what directions enterprises themselves should take in order to gain advantages from its adoption. Whether an enterprise is going to plan for SOA design or not, there are three major difficulties they have to deal with:

• Roles involved. Even when designing simple business services, many company roles are involved, therefore many skills play on the same ground using possibly different tools
• Implementation model. Being it either Waterfall, Synchronized or Single, a certain number of tools is required to support it. Even if marked with the same brand, platforms for implementing SOA are often a collection of different tools, sometimes not well integrated
• Organizational issues. They are much more complex than technical ones, and they often require a cultural change in order to be addressed

Sense software platform leverages on its SPOA (Single Point Of Accountability) key concept to go one step beyond SOA and address the above points. This paper illustrates how Sense implements SOA paradigm and how SPOA model offers a way to facilitate the cultural change needed to better exploit technology benefits.

A real-life scenario
The complexity underneath the development of a business service does not depend on the service itself. It depends rather on the complexity (organizational, cultural) of the company. Incredibly simple requests may require long time and a great amount of money to be accomplished.

Roles involved
Within a big company, many distinct roles have to participate to the entire process, from inception (business modelling) to the execution (operation). All roles belong to three major areas:

• Business. Basically the business owner and the business analyst refer to this area. They are responsible for high level description of business goals and for detailed description of business flow, data flow and user interaction
• Architecture. The technical architect translates business concepts into executable units with algorithms to be developed and/or systems to be used
• Operation. One or more professionals are required to develop, test and deploy the service designed by the architects. An additional role is required to monitor service execution and ensure its performances

From 3 to 7 (or even more) different roles are required to implement a business service. The number cannot be smaller and in a normal situation this results in delays, misunderstandings, different (sometimes incompatible) point of views. SPOA model (as described later) does not allow to decrease the number of roles, rather it offers an approach to service development that avoids most of the problems mentioned above.

Implementation model

There are three major models that companies use to control service lifecycle. Namely, they are the Waterfall Model, the Synchronized Model and the Single Model, as depicted in the picture below.

The Waterfall Model is a one way process (from business to operation) where every role uses its own tool/repository. The constructs of each phase are passed to the following one. Any change in any phase has to be manually managed.









In the Synchronized Model all roles belonging to Business and Architecture share a common part of the model, thus allowing a lot of information to be consistently maintained through the lifecycle. Actual benefits of this approach do depend on tool features.











The Single Model is the best one in terms of simplicity. One single model is shared among roles, and each one of them may use specialized tools, without affecting the model itself.





Organizational issues
The bigger the company, the bigger the number of roles/groups involved in the development lifecycle. It is not infrequent to bump into difficulties like misunderstandings and delays. In other words, different perspective or different processes that take part in the overall design may contrast one another.

BEYOND SOA IS SPOA!

The actual implementation of SOA within enterprises has to face the above problems, making it difficult to achieve the benefits of SOA. Sense – SENsitive Services Environment fully implements SOA and goes beyond it, with the concept of SPOA – Single Point Of Accountability.

The major concern of SOA is the architecture.
It has to deal with services in a technical perspective. Services, in IT world, are merely responses to invocations. No more than results of algorithms. Or, from a higher point of view, they are objects running on an underlying middleware. This has little to do with clients and customers, who think of services as real answers to real requests.

The major concern of SPOA is the business service. Whatever middleware is responsible for making objects running, in customer perspective the service is (for example) his/her balance displayed on his/her mobile phone, at any hour, with a good response time.
It is the business service (that is, the customer) to set the rules that will drive development, and those rules will live inside the service as long as it is running.

With Sense the service is a single point of accountability, from business design to operation execution. The more the design proceeds, the bigger the number of perspectives that converge on the service. Every perspective “added” on top of the service will result in a new Service Level Agreement (SLA) that represents and guarantees the goals of that particular perspective.

Sense implements the Single Model of development, letting every role involved in the entire process add its own information and set its own constraints. Even if a certain role uses its own tool (not integrated with the others), this will result in adding a SLA (Service Level Agreement) on the service, and that SLA will affect service execution over its life.

Sense and SPOA help companies solve their organizational issues. Software platforms, including Sense, will never be the answer to the organizational issues described, that mainly depend on the behaviour of individuals.

Nevertheless, Sense and its SPOA key concept bring a really new approach to development.
It focuses on cooperation: multiple roles converge on the same object, everyone of them being responsible (accountable) for its own perspective (SLA), while the object remains the same. It is a cultural change, that leads to improvement and higher awareness.

CONCLUSION

Looking at future plans for software developments, companies think of SOA as the paradigm to protect IT investments and exploit all the potential of information systems. When approaching SOA at enterprise level, three categories a problems arise: the number of roles involved, the development model and the organizational issues. All these seem to weaken SOA potential.

Sense - SENsitive Services Environment platform and its SPOA key concept, offer a way to build SOA applications and realize the promises of the paradigm. Instead of adding a new set of tools, SPOA redefines the concept of service, allowing it to escape from the cages of technical issues and go closer to who is the source of company profits, that is the customer. Once redefined, the business service collects perspectives over its design process, each one reflecting the point of view of the role that set it.

The task of redefining the service is both technical and cultural. In this way Sense introduces a different approach, that brings a decrease in development time, a more effective process and a better understanding of company goals. In Sense environment, it is called Enterprise Common Sense.

mondora releases the Oblique Scaling™

Is there a missing piece between Virtualization, Management, and Application stack? Yes. Applications speak languages not understandable from Virtualizaton platforms resulting fully unmanageable.

Applications cannot rise to the world they're suffering and everything is managed only when system is broken. The only things IT managers can do is restarting machines, switching on cpu and other things. A new approach is to monitor the system trying to anticipate suffering by monitoring CPU and other stuff.

This approach is making some Sense in Operational Management but does not making Sense in terms of business, because it tries to predict on some hardware collected data against what are real business needs.

This approach is a bottom up approach where Hardware drives Software and then Business. Hardware is like Software a vehicle for helping business and not a driver.

Imagine if a hardware producer wants to sell "normal power" and "extra power" in a startup company. "Normal power" is the basic expectation in terms of business: what will be really the next days Business; "extra power" is something that is unpredictable and everyone look for it (a big success on a campaign etc.).

This is the way! The preferred approach is to let Business to drive how the application is suffering and then choose the right policy to make it profitable.
This approach is preferred in term of Return Of Investment where the Application and Hardware are considered as a unique infrastructure that is adapting to business needs and not conversely.

Sense is a platform that is able to describe how a system is performing during time and to switch over Application nodes by anticipating possible faults. During time, Horizontal Scaling cannot be enough; the Application needs more Power by Vertical Scaling, and usually we have available "time slot" of cpu times.

In mondora, Horizontal and Vertical Scaling is handled as an Application Feature crosscutting the business behaviors. Like High Available Services available in the System Federation, of a SOA System, with different Protocol, and different Service Level Agreement configuration, mondora enable your application to perceive Hardware as an external service itself. Considering it as a High Available Service Hardware can be instrumented with a Service Level Agreement specification and self tuned, meeting business best value, while business is computing.

Sense implements Several levels of Service Statuses; this let the system to predict when is overloading and choose which is the best strategy to let the system survive.

This is done prior that a fault occurs letting the application to feel if things are going badly in terms of business.

Different strategies can be implemented when choosing, from the business point of view, how to scale.

Business is driving and mondora has produced several implementations.

For example:
- Worst Performance, Increase Power
- Latency vs Operational Time

All the above strategies are implemented and deployed -plug-ins at runtime- as Scent that enables to switch on (and off) only the needed power to let the application run meeting SLA.

This is like the common Virtualization layer, but adds more: add rule from the business to address saving; every type of saving, from energy power saving to operational costs saving. Requirements to get saving shall have hardware that enable powering on/off parts, without switching buttons. Sense will drive your saving, to meet declared SLA.

Traditional Virtualization is under the hood and is perceived by the Application, this let Application that makes Sense to Vertical Scale on several platforms.

for further information about oblique scaling contact sense@mondora.com

Openldap and HP UX: industry strength solution

Enterprise computing requires industry strength behavior that can survive across a big amount of data and an increasing overload.

The Open source is sometimes not appreciated because it is thought as "not ready" for the Enterprise Era.  

In these days, I and a good fellow Paolo are testing Openldap for performances in an Enterprise Architecture.

Stress Task goals are given with a short anticipation, last Thursday, and results must be produced in a short time: next Monday at 12.00!

I love to approach everything having those objectives:

- learn something new;

- produce something valuable;

- enjoy meanwhile, stressed.

Starting from the "learning something new," what's better if you have two HP machine partitioned on four VPAR having on each machine 64GB of memory and 300GB of disk. Ok HP UX is not so easy to be understood as linux is, but having Bash on it, it becomes easier.

I like doing a job in pair, because:

- knowledge transfer is facilitated;

- stress is propagated.

Our client configuration for processing huge LDIF file (millions of entries) is a Mac Pro 8core, and our client machines to work with are our Mac Book Pro; a 17" and a 15."

To better see what's going on, an Apple 30" Cinema Display is connected to the 17" MacBook and to have each client interface on each client interface we:

- connected an external keyboard and mouse, through the Cinema Display, having a user to work together on the same computer;

- shared thought VNC the 15" macbook, that is the client for doing documents, writing wikis browsing the net to find useful ldap PATCHES.

In terms of software, after a quick look over the net, we've chosen SLAMD as our helper in doing stress tests.

SLAMD is a Sun iPlanet opensource implementation thought mainly to do Jobs on an LDAP server. It is a Web Application, written in Java, and runs in a Web Container like Tomcat. We configured SLAMD on a virtual partition near the master ldap server.

SLAMD is a good tool for doing Stress tests with much native feature that, in our case, are covering all the test cases. We've chosen this tool because time to market of our stress test report is really short. In three days we have to configure the platform, run differently kind of tests and produce hi quality report. And SLAMD is a tool that gains lots of our requirements:

1. It is strongly LDAP oriented

2. It is fully web administrable and configurable

3. It organizes distributed client over the net in the Grinder fashion, with the Idea of Distributed Computing Agents

4. Jobs can be scheduled during time with simple clicks

5. It implements a report engine that exports pdf, html, text report having graph and statistical information collected

6. It's easy to install, just untar and launch (in the tomcat edition)

During stress testing, system has been monitored having Glance running on each single VPAR, monitoring CPU’s performances. HP GLANCE fulfills the need for a simple to use, simple to understand performance product that examines what is happening now on a system. It displays the usage of the three critical system resources (CPU, Disc, and Memory) from a system wide point of view and then highlights programs which are being a run that is of special interest. HP GLANCE allows you to isolate a particular job, session

or process for additional detail, if desired.

Testing approach

Tests were conducted to observe how system works under different load, measuring the average response time, peaks and other useful information.

Since the first test the above architecture, having Master, and Slave connected is respected. The main statement in doing tests’ run is that: it doesn’t matter if a test relies only to a component inside the architecture; it shouldn’t be isolated while stressing atomically it. This to guarantee and to monitor not only the single component but to watch a single component in a complex system.

Variables during testing are a multitude of information and span across:

• time of testing;

• number of operations;

• when and where execute operations;

• level of concurrency;

• level of randomness;

Variables during testing shift with these criteria:

Variable	Starting from	Moving to	Comments
Users	1 million	2 millions	first system setup
Users	2 million	6 millions	stress testing
Stress Period	10 minutes	60 minutes	initial load
Stress Period	60 minutes	180 minutes	work load
Stress Period	180 minutes	720 minutes	endurance test
Thread per client	1	5	Endurance stress test

Testing has been approached thinking concurrent client with a factor level for update, delete, search and add.

The concept of User is a set of complete Entries from the inetorgperson.schema.

1st benchmark test: 1 million user - 3 concurrent slave

This test has been conducted to check the whole infrastructure having a Master under write stress and slave to read the just replicated information.

Configuration	Values
writes per seond	20 tx/sec
Number of slaves	3 slaves
Shared memory	4 GB
Customer Base	1 million
Replication mechanism	slurpd
Test time	10 minutes

Test has produced:
average search response 0,6 msec

Having Shared Memory:

Text RSS/VSS:2.5mb/3.8mb
Data RSS/VSS:1.7gb/1.9gb
Stack RSS/VSS: 32kb/ 32kb
Shmem RSS/VSS:3.3gb/4.0gb
Other RSS/VSS:9.5mb/152mb





Test Considerations
Overall has been done 11.786 ADD on the master node, and has been verified that the propagation on the 3 slaves throught Slurpd daemon went successfully. During Slave’s synchronization, 3 different jobs were stressing those 3 slaves reading and having a performance of 0,6msec each transaction, doing Random Search.


2nd Benchmark test: 2 million user - 3 concurrent slave

This test has been conducted to check the whole infrastructure having a Master under write stress and slave to read the just replicated information.

Configuration	Values
writes per seond	20 tx/sec
Number of slaves	3 slaves
Shared memory	4 GB
Customer Base	2 million
Replication mechanism	slurpd
Test time	10 minutes

Test has produced:
average search response 0,592 msec

Having Shared Memory:

Text RSS/VSS:2.6mb/3.8mb
Data RSS/VSS:2.0gb/2.2gb
Stack RSS/VSS: 32kb/ 32kb
Shmem RSS/VSS:2.7gb/4.0gb Other RSS/VSS:9.2mb/111mb






Test Considerations

Overall has been done 2.850 ADD, 3084 DELETE, 5875 UPDATE on the master node, and has been verified that the propagation on the 3 slaves through Slurpd daemon went successfully. Meanwhile The Master replicated to slaves, 3 different jobs were stressing 3 slaves reading having a performance of 0,592 msec each transaction, doing Random Search.

3rd Benchmark test: 6 million user - 3 concurrent slave - 10 mins run 1:2:1

This test has been conducted to check the whole infrastructure having a Master under write stress and slave to read the just replicated information.

Configuration	Values
writes per seond	20 tx/sec
Number of slaves	3 slaves
Shared memory	16 GB
Customer Base	6 million
Replication mechanism	slurpd
Test time	10 minutes

Test has produced:
average search response 0,485 msec

Having Shared Memory:

Text RSS/VSS:2.5mb/3.8mb
Data RSS/VSS:5.6gb/6.6gb
Stack RSS/VSS: 32kb/ 32kb






Test Considerations

Overall has been done 206.614 ADD, 224.583 DELETE, 427.186 UPDATE on the master node, and has been verified that the propagation on the 3 slaves through Slurpd daemon went successfully. Meanwhile the Master replicated to slaves, 3 different jobs were stressing those 3 slaves reading and having a performance of 0,485 msec each transaction, doing Random Search.

4th Benchmark test: 6 milion user - 3 concurrent slave - 10 mins run 10:1:1:1

This test has been conducted to check the whole infrastructure having a Master under write stress and slave to read the just replicated information.

Configuration	Values
writes per seond	20 tx/sec
Number of slaves	3 slaves
Shared memory	16 GB
Customer Base	6 million
Replication mechanism	slurpd
Test time	10 minutes

Test has produced:
average search response 0,488 msec

Having Shared Memory:

Text RSS/VSS:2.5mb/3.8mb
Data RSS/VSS:5.6gb/6.6gb
Stack RSS/VSS: 32kb/ 32kb






Test Considerations

Overall has been done 3.975 ADD, 3.977 DELETE, 3.817 UPDATE on the master node, and has been verified that the propagation on the 3 slaves throught Slurpd daemon went successfully. Meanwhile The Master replicated to slaves, 3 different jobs were stressing those 3 slaves reading and having a performance of 0,488 msec each transaction, doing Random Search.





5th Benchmark test: 6 million user - Random search

This test has been conducted to check the whole infrastructure having a Slave under read test on a random cluster.

Configuration	Values
writes per seond	20 tx/sec
Number of slaves	3 slaves
Shared memory	16 GB
Customer Base	6 million
Replication mechanism	slurpd
Test time	10 minutes
Random Cluster Size	1 million

Test has produced:
average search response 0,436 msec

Having Shared Memory:

Text RSS/VSS:2.5mb/3.8mb
Data RSS/VSS:5.6gb/6.6gb
Stack RSS/VSS: 32kb/ 32kb
Shmem RSS/VSS: 11gb/ 16gb
Other RSS/VSS: 10mb/160mb




Test Considerations

Overall has been done 1.357.628 on the slave node against a cluster of a 1.000.000 random users.


6th Benchmark test: 6 million user - Update - Modify - Delete - 600msec

This test has been conducted to check the whole infrastructure having a Master under write stress and slave to read the just replicated information.

Configuration	Values
writes per seond	20 tx/sec
Number of slaves	3 slaves
Shared memory	16 GB
Customer Base	6 million
Replication mechanism	slurpd
Test time	10 minutes

Test has produced:
transaction per second: update: 236,4
transaction per second: add: 236,877
transaction per second: delete: 236,4

Having Shared Memory:

Text RSS/VSS:2.5mb/3.8mb
Data RSS/VSS:5.6gb/6.6gb
Stack RSS/VSS: 32kb/ 32kb
Shmem RSS/VSS: 11gb/ 16gb
Other RSS/VSS: 10mb/160mb







Test Considerations

Overall has been done 141.081 ADD, 141.160 DELETE, 141.021 UPDATE on the master node, and has been verified that the propagation on the 3 slaves throught Slurpd daemon went successfully.







7th Benchmark test: 6 million user - 10:1:2:1- 12 hours

This test has been conducted to check the whole infrastructure having a Master under write stress and slave to read the just replicated information.

Configuration	Values
writes per seond	20 tx/sec
Number of slaves	3 slaves
Shared memory	16 GB
Customer Base	6 million
Replication mechanism	slurpd
Test time	12 hours

Test has produced:
transaction per second: search 1984,697
transaction per second: update 9,890
transaction per second: add 4,991
transaction per second: delete 4,991

Having Shared Memory:

Text RSS/VSS:2.5mb/3.8mb
Data RSS/VSS:5.7gb/6.8gb
Stack RSS/VSS: 32kb/ 32kb
Shmem RSS/VSS: 11gb/ 16gb
Other RSS/VSS: 11mb/168mb







Test Considerations

Overall has been done: Search: 67.070.660, Modify: 427.186 (49.766%); Delete: 224.583 (26.163%); Add: 206.614 (24.070%) on the master node, and has been verified that the propagation on the 3 slaves throught Slurpd daemon went successfully.





8th Benchmark test: 6 million user - 10:1:1:1- 1 hours with concurrency only on master

This test has been conducted to check the whole infrastructure having a Master under write stress and slave to read the just replicated information.

Configuration	Values
writes per seond	20 tx/sec
Number of slaves	1 master
Shared memory	16 GB
Customer Base	6 million
Replication mechanism	slurpd
Test time	1 hour

Test has produced:
transaction per second: search 969,444
transaction per second: update 96,760
transaction per second: add 97,077
transaction per second: delete 96,967

Having Shared Memory:

Text RSS/VSS:2.5mb/3.8mb
Data RSS/VSS:5.7gb/6.8gb
Stack RSS/VSS: 32kb/ 32kb
Shmem RSS/VSS: 11gb/ 16gb
Other RSS/VSS: 11mb/168mb








Test Considerations

Overall has been done: Search: 67.070.660, Modify: 427.186 (49.766%); Delete: 224.583 (26.163%); Add: 206.614 (24.070%) on the master node, and has been verified that the propagation on the 3 slaves throught Slurpd daemon went successfully.






9th Benchmark test: 6 million user - 10:2:2:2- 1hours with concurrency only on master

This test has been conducted to check the whole infrastructure having a Master under write stress and slave to read the just replicated information.

Configuration	Values
writes per seond	20 tx/sec
Number of slaves	1 master
Shared memory	16 GB
Customer Base	6 million
Replication mechanism	slurpd
Test time	1 hour

Test has produced:
transaction per second: search 678,123
transaction per second: update 135,643
transaction per second: add 135,703
transaction per second: delete 134,770

Having Shared Memory:


Text RSS/VSS:2.5mb/3.8mb
Data RSS/VSS:5.7gb/6.8gb
Stack RSS/VSS: 32kb/ 32kb
Shmem RSS/VSS: 11gb/ 16gb
Other RSS/VSS: 11mb/168mb


Test Considerations

Overall has been done: Search: 67.070.660, Modify: 427.186 (49.766%); Delete: 224.583 (26.163%); Add: 206.614 (24.070%) on the master node, and has been verified that the propagation on the 3 slaves throught Slurpd daemon went successfully.






10th Benchmark test: 6 million user - Random search

This test has been conducted to check the whole infrastructure having a Master under write stress and slave to read the just replicated information.

Configuration	Values
writes per seond	20 tx/sec
Number of slaves	1 master
Shared memory	16 GB
Customer Base	6 million
Replication mechanism	slurpd
Test time	1 hour

Test has produced:
average search response: 1.686 msec

Having Shared Memory:

Text RSS/VSS:2.5mb/3.8mb
Data RSS/VSS:5.6gb/6.6gb
Stack RSS/VSS: 32kb/ 32kb
Shmem RSS/VSS: 11gb/ 16gb
Other RSS/VSS: 10mb/160mb





Test Considerations

Overall has been done 17.976.344 on the slave node against a cluster of a 1.000.000 random users.
Delete: 224.583 (26.163%); Add: 206.614 (24.070%) on the master node, and has been verified that the propagation on the 3 slaves throught Slurpd daemon went successfully.


Conclusion

Openldap has performed really well on the HP UX Cluster environment; during all the test phase no restart of Slapd has been required and no restart of Slurpd has been done.

Openldap and HP UX, has been used AS IS and is not tuned for better performing. Openldap has been patched with the Official patches available online.

VPAR configuration has been tested while Openldap was running having Core hot enabled during run time.