Kitchens in the Zoo

How Brontosaurs kill Raptors

The board of a large organisation appoints a CIO who delegates technical decisions to his employees. In the Enterprise Architecture (EA) department, an expert on Business Intelligence (BI) decides that the strategy for this company is to have a single Enterprise Data Warehouse (EDW). This makes sense, because experience has shown that in the long run, it is cheaper and more efficient to build one Data Warehouse, rather than start by building "islands" and then later try to merge them together.

In the mean time, some business people working for the company have rallied the budget holders, and started a project to build a new online sales application. They need to generate some reports based on the sales from this application, in order to set themselves targets and measure their performance. But, they are not experts when it comes to reporting. The business sector at which their application is aimed is cutting edge and brand new, so they don't know what to expect, they don't really know what kind of reports they will need, and they will certainly need to adapt to the market very quickly.

A project team in the IT department then get the assignment to build the application, including the report generation. Also knowing little about reporting, they start talking to EA, who set up a meeting, between themselves, the development team, some people from the Quality Assurance (QA) department and some experts from the BI team. Hours of discussion later, they have made the following conclusions:

Company IT Strategy states all reporting must be implemented in the BI solution, to ensure there is only one EDW,
The BI team are the only experts of the BI system,
The BI team cost a lot, because they are using SAP and consultants (how many SAP guys aren't freelance?),
The BI team dictate a six monthly release cycle, no exceptions,
The BI system is a black box, its inner workings stay secret within the BI team.

So, a simple question arises... "Our customer doesn't know exactly what they want, and because of their business requirements, they need us to be agile. What do we do and can the BI team help?", the development team ask. The first answer skirts around the issue and doesn't actually deserve being called an answer, because it doesn't answer the question. The development team make the point that the question hasn't been addressed, to which another attempt to avoid the question is made. Clearly, either these people don't understand their businesses needs, or they know they can't help but won't admit it. Either way, the debate moves on.

Days later, the business guys are telling some colleagues about their cool new project over an espresso and a latte. "Hee hee hee, hoo hoo hoo...", laugh their colleagues. "We thought our reports would let us track our progress too, but the IT department screwed us over. They charged us double and delivered nothing useful. We tried to submit some change requests to get it working and all the IT department wanted was more money and they couldn't deliver the changes quick enough anyway!"

The cool business dudes ran over to the IT office, informed their development team about the new information and said, "Guys, we don't want you to use BI. Well not for the first release anyway. Maybe in a year or two. Sure, it's policy and all, but we don't know what we want, and need to gain some experience, so just hack those reports out within budget please!".

So the development team arrange another meeting with the ~~astronauts~~ EAs and QAs to get that unanswered question answered, and they talk about the customers concerns. Even if it's an over reaction, the point is, that another department needs to be involved meaning more communication, less visibility and hence greater costs and risks. "Sure, no problem if the requirements are stable and known, but this project needs agility", is the point the dev team makes. "Well, no, not a chance!", comes the response.

"In fact," they continue, "you simply need to go back to the business and tell them that their idea is an architecture infringement - it goes against company policies. You won't pass QA, you won't get the go ahead to go into production, and that's the end of it", comes the reply.

A solution oriented response indeed... "Furthermore," continues an EA, " the business doesn't have the right to come into our shop and tell us where to implement things and where not to. We are the experts in the technology domain. We make these choices."

Well, his argument is that the business hired the CIO, who delegated responsibility to a BI expert, who created a non-agile policy. So the business have to swallow the argument and accept that the IT department is shit and won't give them solutions which they need, to compete in new markets... I'm not sure he realises that this is his argument, but it is, if you look at it pragmatically.

I'm not sure the cool business dudes see it that way either. I know I don't see it that way. And I know of no solution oriented architect or developer who sees it that way.

Of course I understand the reasons we have EA, QA, Processes and Policies. For large organisations they are the only way to avoid utter chaos, amongst many other reasons. Most of my working life has been spent with large organisations, even though in many cases I was allowed to implement agile solutions. But, after a long day in the office, with some frustrating decisions, I need to rant, so here is my cynical view of EA, QA, Processes and Policies, albeit somewhat harsh: these are all things which get bigger, the larger a company is, and all things which let people hide behind their responsibility of providing the business with the solutions they need. They all cause large corporations to be compared to large dinosaurs. These departments seem to have forgotten one golden rule: if the business fails, those departments won't exist. In competitive markets like we have today, businesses, no matter how large, need to stay competitive, and they can do so by using IT departments which are able to deliver agile solutions. These departments also often remind me of self-perpetuating witch doctors (The Witch Doctors, ISBN 074932645X). They justify themselves by stating that the business learned the hard way and now that they have been built up they cannot possibly be removed or have power taken away, like we some how never managed to go live before they existed, or that small companies can't exist because they don't have them.

Copyright © Ant Kutschera

Social Bookmarks :

Persistent State Machine with Apache SCXML

The source code for this blog article can be downloaded here.

I'm bored of reinventing the wheel. Everytime I need a state machine to ensure my states traverse only valid transitions, I find myself either not bothering, because I trust my coding (and write all the necessary unit tests of course), or writing very similar code over again.

So I started wondering if there was a configurable state machine out there somewhere, and in no time at all Google gave me a link to SCXML from Apache. Apache SCXML is an implementation of a configurable state machine based on the SCXML working draft from W3C.

I started by taking a look at what it does and how it works, always keeping in mind my requirements based on previous projects. The main question was how I could use a state machine in a persistent entity so that when an attempt is made to change the state, the state machine validated the attempt, ensuring only valid transitions are carried out. That meant two things:

The state machine had to be able to have its current state set to any state. If I load an object with state out of the database, I need to be able to set that state in the state machine so that it checks any attempts to change state, based on this starting state.
The state machine had to fit into a JPA entity class so that I could persist and load the state.

Apache SCXML doesn't come with great documentation but if you look around, it has some "use cases" which are examples of how you can use it. It comes with the class org.apache.commons.scxml.env.AbstractStateMachine which uses reflection to trigger transitions. I went for a slightly different approach and created the uk.co.maxant.demo.scxml.util.AbstractStateMachine, which wraps an instance of the SCXMLExecutor (the "engine", or state machine itself). By wrapping the state machine, I am able to provide two extra benefits:

I can construct the state machine using the starting state out of a persisted entity, rather than being forced to use the state charts initial state. The implementation details of this construction are a little complicated so my abstract wrapper can hide the details from the caller who is more interested in writing some business code, rather than boiler plate code.
I can enforce only valid state transitions, in that before performing a transition, I can use the state machine to check if its a valid transition from the current state. Apache SCXMLs default handling means that if you try to set the state to an illegal state, the state machine simply does nothing. I prefer to be a little harsher and throw an IllegalStateException!

The implementation of the AbstractStateMachine contains trigger methods for changing state via transition events. Each event makes a simple call to the AbstractStateMachine.trigger(String) method which first of all checks that the current state allows the transition, and second of all delegates the transition to the wrapped state machine instance. If the requested state transition is illegal, then an IllegalStateException with details of the problem is thrown. I too, could have also used reflection like the Apache example, but prefer to write more readable code for this Blog.

Apache SCXML is built up by creating an SCXML instance which is based upon the configuration which is an XML representation of the state chart and can be generated from UML. As such, this configuration has an initial state, as defined in your state chart. You then create an instance of the engine (state machine, SCXMLExecutor) which is responsible for running with the configuration. For performance reasons, the configuration should only be created once, as it parses the XML document. In my demo, I instantiated it at class load time in the subclass of AbstractStateMachine.

So what do you do, if you are loading an object from a persistent store like a database and you want to instantiate your state machine (SCXMLExecutor) with a state other than the initial state? Well, it's quite easy, you simply use the API to modify the current state of the state machine (SCXMLExecutor) instance and set the initial state to be that, which your persisted entity currently has. The method isn't setCurrentState(), rather you use the current state object, and remove its states and set the relevant state which you retrieved from the configuration (SCXML). Have a look at AbstractStateMachine.setInitialState(SCXMLExecutor, String) to see how. Thanks to the SCXML team for showing me how to do this!

So having done all that, I was now in a position to use the state machine to manage the state in a persistent entity. I created a database table with a varchar column for holding my state, and primary key. In the real world, the state would be part of a much larger entity with other fields. I then setup my Eclipse project to contain the JPA facet and by right clicking on the project was able to generate my JPA entity classes from the table, such as shown in the SomethingPersistentWithState class. The only special thing I did, was to select "property based access" as the way in which JPA accesses the attributes. Normally, and by default, JPA uses field based access, i.e. it uses reflection at runtime to get and set the class attributes. By selecting "property based access", Eclipse generates an additional Annotation on my entity class: @Access(AccessType.PROPERTY). I then had only three things to do:

Change the "state" class attribute from a String into an instance of StateMachineDemo, which is the implementation of AbstractStateMachine. I can do this, because the above Annotation means that JPA doesn't care how I implement the attribute, is will always use bean conform accessors to set/get the state of my entity, namely the String getState() and void setState(String) methods.
Change the generated void setState(String) method visibility to become private, so that no one could explicitly set the state of my entity. The method needs to exist, so that JPA can access the attribute to persist it, but JPA can happily live with the method being private.
Add methods for each transition, which simply delegate the call to the state machine. Users of the persistent entity use these trigger methods to change the state, rather than calling void setState(String) on the entity.

These changes are all shown/documented in the StateMachineDemo class.

To demonstrate the state machine working, as well as it being used in a persistent environment, have a look at the JUnit test case StateMachineDemoTest. This class contains tests for setting any state during construction, tests for state transitions proving that only valid ones are allowed, as well as reading/writing an entity containing state to the database and updating the state along the way.

Download the source here.

© 2010, Ant Kutschera

Social Bookmarks :

Waffle Theorem

Eating a waffle, I just developed a new theorem. First assume the waffle is square and made up of little squares. If, like me, you eat around two edges, one square deep, so that the waffle stays square, you ALWAYS eat an odd number of squares. Eg. 6x6, you eat 6 mini squares, follwed by 5, making 11 (odd number), so that the waffle itself stays square, now only 5x5. My theorem hypothesises that this is true for all waffle sizes. In fact it's called the "Waffle Theorem", and here is the mathematical proof:

y = x^2 - (x-1)^2

-> y = x^2 - (x^2 - 2x + 1)
-> y = 2x-1.

QED, because 2 times anything ("2x") is always even, and subtracting one ("-1") always makes an even number odd. Hence my hypothesis holds true, regardless of waffle size.

Not bad for a Sunday night, all I wanted to do was eat the damn waffle... I have to say though, it's this kind of thing that I love about maths.

-----------------

Social Bookmarks :

Taking Advantage of Parallelism

A while ago some colleagues attended a lecture where the presenter introduced the idea that applications may not take full advantage of the multi-core servers which are available today. The idea was that if you have two cores but a process which is running on a single thread, then all the work is done on one single core. Application servers help in this respect, because they handle multiple incoming requests simultaneously, by starting a new thread for each request. So if the server has two cores it can really handle two requests simultaneously, or if it has 6 cores, it can handle 6 requests simultanously.

So multi-core CPUs can help the performance of your server if you have multiple simultaneous requests, which is often the case when your server is running near its limit. But it's not often the case that you want your servers running close to the limit, so you typically scale out, by adding more nodes to your server cluster, which has a similar effect to adding cores to the CPU (you can continue to handle multiple requests simultaneously).

So once you have scaled up by adding more cores, and scaled out by adding more servers, how can you improve performance?

Some processes can be designed to be non-serial, especially in enterprise scenarios. The Wikipedia article on multi-core processors talks about this. Imagine a process which gathers data from multiple systems while preparing the data which it responds with. An example would be a pricing system. Imagine your local zoo offered a web service for purchasing individual tickets, say an entrance ticket, a voucher for some tasty elephant snacks for feeding time, a voucher for their shop for getting gifts before you leave, etc. Now imagine, you as an entrepreneur wanted to open a re-selling business offering packages for such products, so that you could offer a discount (greater sales volume, lower per-item profit).

A perfect way to do this would be to partner with the Zoo and offer a website which integrates with the zoo's web service and sells such packages. You implement your website, but then while doing performance tests, you notice that regardless of load, an average sales is taking 3 seconds to complete. You analyse the system and determine that its the zoo's web service which is the problem - each product quote is taking a full second to get. You talk to the zoo's IT department, and they confirm that this is known, but there is little they can do about it because in the back end they are using complex reservation systems which work out a dynamic market price which is based on supply and demand.

So, you go away and have a think, and remember that your data center has just just installed some servers with flashy new multi-core processors, which are costing you a fortune. Then it hits you! Getting a product quote is an independent task. So while getting quotes for the items in your package, you might as well do it in parallel, at the same time! Hang on now. You implemented your system in Java and the business logic is in EJBs, so there's no chance of spawning new threads, the container won't let you! Except... you implemented it on a shiny new Java EE 6 server! Hooray! Why? Because of the javax.ejb.Asynchronous annotation.

The Javadocs for this annotation state:

Used to mark a method as an asynchronous method or to designate all business methods of a class or interface as asynchronous.

So, what you do, is add this annotation to a business method of your EJB and the container runs it on a new thread. Brilliant! The only minor issue is how to get the result from your asynchronous calls, but that's relatively easy, using the Future<T> class. Consider the following method declaration:

/** * note that async methods implicitly start new transactions! * see ejb 3.1 spec, chapter 4.5.3. */ @Override @Asynchronous @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) public Future getOffer(Product product, UUID purchaseId) { . .
This EJB business method takes a product and purchase ID (effectively a session ID). It gets called by the container on a new thread, which implicitly means that it cannot re-use any existing transactions and must hence be run using a new transaction (see EJB specification, chapter 4.5.3). This method then calls the zoo's web service and when it gets a response, returns the response:

return new AsyncResult(o);
where "o" is an offer - the response from the web service call. The javax.ejb.AsyncResult<T> class is the standard implentation of a Future<T>, and simply wraps the actual object you want to return.

The EJB which started the async calls knows when they have all returned, because it can check the results isDone() method. As soon as the new thread completes, the container sets this method to return true.

So, the net effect is that instead of taking three seconds to get an offer for your package of three items, it only takes one second! A whopping 300% improvement!

The async annotation in the EJB spec is a welcome extension. If also offers the ability to cancel tasks as well as handle exceptions from the async calls (via ExecutionExceptions which wrap the problem). With it however, there are some dangers, as suggested in the Wikipedia article on multi-core processors. The fact that such async methods are forced to start a new transaction can cause problems. However, this is actually an advantage, because we are calling web services! Web services are inherently non-transactional. That means they are committed as soon as you get their response, not as soon as your transaction is committed. So in order to make web services XA (two phase commit) compatible, one normally adds a "commit" method to the web service which the caller must call when all their business logic is complete, or one adds a mechanism for cancelling such transactions.

I have used the new "inner" transaction which the container starts to track the state of these offers / sales. As soon as the web service returns, I write the result to a table in the database with its status "OFFERED", so that I know I have not actually purchased it. Regardless of errors in other calls to the web service, I am guaranteed to have such an entry for each successful web service result, due to the inner transaction. After I get the three offers, the orchestration EJB which called the async bean (which calls the web services), purchases the three offers. After each purchase, I update the status in the database to "BOUGHT", also using an inner transaction (REQUIRES_NEW), so that regardless of any failures in subsequent purchases, the state of individual purchases is known. Why go to this effort? Well, I have a business rule: my packages are sold as complete packages, or not at all! So if any single purchase fails, I need to cancel my other purchases. If I don't, I still owe the zoo for what I have purchased, and I didn't get any money from my customer, because the package failed!

The solution is to use the timer service from the EJB container. I schedule a method in an EJB to analyse my offers/purchases and for any incomplete session (purchase ID), I cancel all three offers and update my records to mark the purchases as "CANCELLED".

I've put this together as a sample app which includes EJB 3.1, Servlet 3.0, Inteceptors, JPA 2.0, the EJB Timer Service, Validation (JSR-303), JMS and JAX-WS, all based on the GlassFish 3 configuration which was blogged at GlassFish 3 In 30 Minutes. The source for this mega sample app can be downloaded here.

Some final quick notes:

1) A web service, and its client cannot be deployed in the same EAR! That makes sense in normal conditions, but for a sample app, where you want your server to call a test WS, it can cause trouble. So the zoo web service is deployed as a simple web project.

2) The Javadocs for the OrchestrationBean provide some more details of the business process.

© 2010 Ant Kutschera

Social Bookmarks :

GlassFish v3, JSF and Virtual Servers

Anyone wanting to run a JSF app on GlassFish may run into problems when migrating to production, if they are hosting multiple domains on their servers by using virtual hosts!

The default deployment, deploys your app to all virtual servers (except _asadmin). If you do that, you get lots of errors, and the app doesn't run.

The solution is easy, simply add the --virtualservers argument to the "deploy" command in the "asadmin" console, and supply the relevant virtual server (just the one).

Hopefully this will get fixed in GFv3.1!

Social Bookmarks :