Java is dead - bugger I'll just do interesting stuff then

There have been a series of articles and blog posts around the impending death of Java, in paticular J2EE because its too complex. Now I've got a couple of issues with this, the first one is that it seems to think that the height of IT sophistication is lobbing a web site on a database, the second is what complex appears to mean these days.

Taking the second point first, is J2EE really that complex? I've been playing about with the latest BEA, IBM, Sun (Glassfish) and Oracle stuff recently trying to work out the "hard" bit. Now what I'm assuming here is that you don't want to actually code stuff if you can avoid that, so I've been using the JSF builders, playing with the new EJB3 data and invocations stuff and also using some of the process engines out there to string things together. Lobbing in some messaging stuff to try out EDA.

Now I'm a manager type these days, powerpoint jockey and creator of word documents, what I mean is that I don't code on a day to day basis these days, development isn't my job anymore. So surely if I can do it, its not that complex. When I compare it with J2EE 1.1 (which I wouldn't have touched with a barge pole) or J2EE 1.3 (the first one I took vaguely seriously) then JavaEE 5.0 is an absolute dream. The presentation stuff is miles easier in JSF than it was in JSP, the EJB bit is a massive step up, and the Glassfish deployment stuff is sooooo much easier than doing it in app servers in 1.1, 1.2 and 1.3.

So where exactly is J2EE more complex for developers? Sure its got a lot of facilities, but I actually found it easier to understand and use, paticularly with the new tools, than previous editions. Now clearly I've only based the assessment on actually using them to knock up some demo apps, rather than on a project. But have the people saying its very complex even downloaded the thing?

Now the other bit about the death of Java, and J2EE, that confuses me is this idea that lobbing stuff on databases is actually an achievement and that Web Sites represent a massively important part of IT. First off you've got the re-architecting of SAP and Oracle application servers (just a multi billion dollar market but hey, its not "sexy") around the J2EE platform, and the consolidation of the integration market around Java, and J2EE. Oh and of course the human workflow and business process markets, oh and pretty much all the RFiD work being done out there, and the whole mobile phone market.

This to me is the thing about Java, sure you could lob up a web-page on a database with Java, but you can also build all of the bits that live everywhere else in the organisation. When looking at SOA this means you are pretty much 100% guarenteed to have Java, and J2EE within your organisation, if not today then certainly when you do that big applications upgrade. I've always been a fan of standardising around a single language for basic development, just because it helps when looking for people and also it means you don't have increased complexity of management and support, and Java tends to stack up as the only valid language for that sort of approach.

So Java is dead, apart from all of the growth that it will drive in the bits of IT that actually represent a challenge, rather than lobbing web-pages on bloody databases.

Technorati Tags: SOA, Java, J2EE, Service Architecture

SOD IT and be proud

Mr Lowe made a comment on his blog recently that I was chastising the use of SOD IT and sure I've had a go at people who mistake SOD IT for SOA, but there is actually another problem in here.

People don't like to admit that they do "development" or "delivery" anymore, its got to be all "architectural" and visionary, strategic and the like. Its a sad state of affairs when people have to dress up a great ability to delivery something as being architecture in the mistaken belief that this makes it more important. SOA is about making the business vision drive IT, but somebody has to turn that vision into bits and bytes which is why SOD IT is actually important.

SOD IT says that traditional delivery models that are based purely around projects need to change to move towards programme management of service projects. SOD IT says that automation of testing at the unit and system test level is critical for ensuring that a service is operating successfully. SOD IT says that requirements should be gathered in line with the services and that development teams should be based around the services. SOD IT is not just the same old technology delivery but this time with a different picture to aim out. SOA fundamentally changes software delivery, it moves it from the project oriented mentality of today towards a business focused view.

So don't dress up the delivery as architecture, its not, be proud of the fact that SOD IT is where the rubber hits the road and the SOA vision is turned into operational reality.

SOD IT without SOA isn't possible, and SOA without SOD IT won't deliver. As much as businesses and IT need to change the way they think about systems and IT in general they also need to change the way they think about the specifics of IT delivery.

So next time you are looking at an IT project and you've already created your business focused SOA and are moving into delivery, remember what Nike say...

just SOD IT.

Technorati Tags: SOA, Development, SOD IT, Service Architecture

SOA and OO its not just data shifting

One of the biggest disappointments that I've had in reviewing Java projects is the death of Object Orientation, sure we have "Customer" as an object but its just about data shifting rather than the objects representing both data and behaviour. The rise of Web Services and the tooling of these is actually making this situation quite a lot worse. So when all of these tools generate objects from services they generate data shifters. The phrase POJO is held up as a good thing because POJOs are simple, and in someways they are, but the question is are these objects becoming far too plain? Logic that was in previous generations hidden within the object is now isolated within classes that could easily be mistake for C programmes, i.e. they just do data processing.

Lets split objects into a couple of layers of intelligence

The data shifter - Basically a C structure in a class file

This is the worst case where the object has just been generated and is a series of get and set methods with precisely zero behaviour, unless you count assignment as behaviour (which I wouldn't). Here you aren't getting any real benefits of using an OO language, as much as you pretend your code is OO its really C code in class files.

Valid fields - Taking the C structure and turning it into Ada

This is still really just procedural code but at least using Ada rather than C. At this stage the XML Schema/Database restrictions have been applied into the generated objects so you can only set valid values into the object. So if you try and set age to "-1" then an exception is thrown calling you a muppet. This level should be the very lowest that a system should stoop to.

Valid Object - Object assures its integrity

The next stage is where the object starts doing more complicated rules, like checking that "Date of Birth" isn't in the future or that "Total" isn't a field its actually a function that adds up all the elements in the "OrderList". This is a good place to be starting from, I've seen several times cases where Order "objects" have a "Total" field that was passed from a Web Service along with the order line and then the total field becomes... well bollocks.

The reason these problems happen is that on one side of the equation (lets say Service A) there is an objection something like

interface Order{

public int getTotal();

public List getOrderLines();

.....

}

and the implementation of getTotal is something like

int returnValue = 0;

for(OrderLine nextLine : this.orderLines){

returnValue = returnValue + nextLine.getValue();

}

return returnValue;

When the WSDL is generated this creates two elements "total" and "orderLines", on the otherside this is the imported and of course the dumb IDE has no clue that total is a function, it just knows it has a value, so now you have a case where while the interface is the same there is now a get and a set function and they both just do an assignment to a class variable.

So when generating these objects you need to make sure that the fields shouldn't really be functions. It would of course be great if there was a way of describing this relationship within the XML document, so it was automatically generated.

My Object - OO designing on both sides

Now the best place to get to would be a recognition that maybe the needs on both sides around behaviour are actually different. The basics around validity will be the same, but the behavioral aspects of the object will be different. So if I'm a supplier of widgets and I work with a supplier of doo-hickies to produce ooojamaflips then my "Customer" object needs to have a "validate" method which checks that the customer doesn't have any outstanding bills, and it makes that check on my local systems. Equally the 4PL that we use to do the assembly needs to check "validate" on customer against its own systems and also needs to have a "notify" method on the order object that sends a message to the customer as its stage and position changes through the supply chain.

SOA doesn't replace OO as a good practice, and the fact that SOA tools generate base classes that are thick is pig-shit doesn't mean you should use them directly. There are wonderful mechanisms in OO like "inheritance" which can enable you to extend these objects with your own service specific behaviour. The piece that should be industrialised is the bit upto "Valid Object" as these rules should be integral parts of what the object is meant to represent. It really is ridiculous that people are still waiting till a database violation occurs before checking that the data is right.

I had a crack with obligate at doing some of the validation stuff, but its custom and not generated (yet) and a bit of a pain for objects. Hibernate has some bits around data validation which is pretty nice, but doesn't really do valid objects yet, and of course is database rather than Service/XML driven. Its one of the sad facts about IT that we appear to take a leap forwards and lose some of our valuables on the way. It will be interesting to see if OO continues to wane or if generally people start realising that OO lives inside the service and that the old OO rules, and benefits, still apply.

Technorati Tags: SOA, Java, WS, OO, Service Architecture

Non-drivers for SOA

When people are establishing their SOA elements one of the important set of elements that gets captured are the principles and drivers for the architecture. What is sometimes over looked, but is equally important, are the non-drivers and non-principles for the adoption of SOA in the organisation. These things fall into two broad groups firstly the common myths of the organisation, and secondly the implementation details that need to be either factored in during implementation, or factored out.

The idea here is to establish the things that either aren't important, or just aren't actually an issue that needs considering. One common one I've found in the last few years is performance, the only times I've seen actual performance issues is when the application has been badly designed or implemented, the capacity of most hardware today really does make performance a secondary concern. If you don't currently have any performance issues then performance is a non-driver for your SOA, this doesn't mean its not something to look at during implementation, but that you shouldn't be optimising your SOA for performance. Another example of these myths is "we can't do that sort of thing here" this is often brought up because some previous IT elements have failed. You really can't afford however to have a driver which is basically acceptance of failure, its something to lob on the risk log but you shouldn't be looking at SOA from the perspective of lowest common denominator.

The second group are the things to worry about later "Our project Management approach doesn't handle services", "I'm not sure how our procurement rules would work", "Our use-case templates don't mention services", "We don't have a services document in the project portfolio and others of that ilk here. These are again non-drivers for the architecture as they are about the things that happen next. This doesn't mean that you sit in an ivory tower appart from implementation but that these are exactly the things that you need to look at once you have a proper service architecture and are looking at how to roll it out across the organisation, these are the operational challenges rather than fundamental barriers.

The point of having these lists of non-drivers is that it helps to close down discussions once you've agree what they are. This helps you to focus on the real drivers and principles and to shutdown pointless avenues that don't deliver any value.

There is a phrase that half of being smart is knowing what you're dumb at, there is an equivalent here, half of good SOA is knowing what is important the other half is knowing what isn't.

Technorati Tags: SOA, Service Architecture

Single Canonical form - not for SOA

A very short while ago I made a post about the starting point for SOA and in the follow-up I made a comment that I wasn't a big fan of canonical data models, and I was asked to clarify why, so here goes.

First off lets agree what we mean by this and I'll take this

Therefore, design a Canonical Data Model that is independent from any specific application. Require each application to produce and consume messages in this common format.

As the definition. I've seen, and led, quite a few projects that have used a canonical data model, and for some things its worked and for lots its failed (of course the ones I led were the ones that worked :) ). So its not that canonical forms are a really bad thing, its just that they aren't the ultimate solution.

Taking the manufacturing service Level 0 as out start
and thinking about product and customer as our two data elements to worry about. There are three approaches here, all of which could be called canonical to some degree but which represent very different approaches to the solution.

Just the facts

The first is the one I've used most often to success in this area, and its focus is all about the interactions between multiple services. The rule here is basically common demoninator, the objective is to find the minimum set of data that can be used to effectively communicate between areas on a consistent basis. The goal here isn't that this should be used on 100% of occasions but that it represents 70-80% of the interactions.

In this model we might even get to the stage where its ProductID and CustomerID that are shared and we have a standard provisioning approach for the two to ensure that IDs are unique. But most often its a small subset that enables each service to understand what the other is talking about and then translate it into its own version. So in this model the "canonical" form is very small, really just a minimal reference set. This does mean that sometimes conversations have to take place outside of this minimal reference set, and that is fine, but its more costly so the people making that call need to be aware that now they are completely responsible for managing change of that interaction.

So in this model we might say that all product elements are governed by the productID, customer consists of Name and Address, but when sales talk to finance to bill a customer for an order they also include the product description from their marketing literature to help it make sense on the invoice. Here we would model this extra bit of information either as an extension to the previous data model, or just consider it bespoke for that transaction. This would mean that the sales service team would now be responsible for the evolution of that data description rather than using the global model which would be owned and maintained... well globally. The objective when communicating is to use this minimal reference set as much as possible, as this reduces effort, and the goal of the team that maintains it is to keep it small so its easier for them.

This model is paticularly effective in data exchange projects like reporting or on base transactional elements, but its the one I've seen used most effectively especially when combined with strong governance and enforcement around the minimal reference set. A great advantage of this model is that it reduces the risk of work being done in the wrong place, if all you have is CustomerID you are unlikely to undertake a massive fraud profiling project, something better off left to finance.

When you talk, we listen

The next approach, and already getting into dangerous territory IMO is to create a superset of all interactions between services. In this world the goal is to capture a canonical form that represents 100% of the possible interactions between services. Thus if a service might need 25 fields of product information then the canonical form has those 25 fields. The problem with this model is that there is a lot of crap flying about that is just there for edge cases. It can be made to work but it makes day-to-day operations harder and tends to lead to blurring of boundaries between areas/services and increases the risk of duplicate functionality. Its also a real issue of information overload. What I've tended to see happen in this model is that people start adding fields "incase" to the model and also start consuming and operating on fields "because they can". This isn't sensible.

I'd like my project to fail please

The final approach is the mythical "single canonical form" this beast is the one that knows everything, its like enterprise but even worse. This one creates a single data model that represents not only the superset of interactions, but the superset of internals as well. So it models both how finance and manufacturing view products and lobs them together, considers how sales and distribution view customer and lobs them together. Once this behemouth is created it then mandates this as the interaction between the areas with (in my experience) disasterous consequences. Its too complex, it removes all boundaries and controls and it ends up with ridiculous information exchanges where both parties known how internally the two areas operate. When external parties are brought into the mix it gets ever more complicated and fragile.

Summary

So I'm not 100% against canonical in terms of an intermediary for data exchange, but I do think that a canonical form needs to be kept very small and compact and that exchanges outside of that canonical form must be allowed for and managed. In the same way as there isn't an enterprise service bus that does everything there is equally no single canonical form that works everywhere. Flexibility comes from mandation for certain elements and increased costs for stepping outside, but stepping outside has to be allowed to enable systems, people and organisations to operate effectively.


Technorati Tags: SOA, data modelling, Service Architecture

Virtualisation and the future application development

For the second time this year I've taken delivery of an dual core (Intel Centrino Duo). The first one I got was the fantastically superb Acer, on which I've installed VMWare. Last week I was asked the quesiton "we've got a Mac Book Pro in the cupboard do you want it?" and oddly I replied "oh okay then". Being a Mac it was of course impossible to connect to our companies systems so on went Parallels and a standard company image (for those using Radia out there in VM land there are some registry elements that need to be removed) went on and soon I was not only connecting to the company network I was also VPN'ing into it.

The Mac is now my "official" company laptop, and the Acer is my "official" development laptop. Mainly because VMWare Server runs like a dream on the Acer which makes running servers really easy, while Parallels is aimed more at a virtual desktop environment which is what I need for Outlook and the MS Office crew.

Running on Dual Core makes this all the more effective paticularly for development, as you can can run the IDE and the native OS in one core and then run a huge array of servers dedicated to the other core (along with the virus scanner and the other annoyances). This sort of model also makes it much easier to start up projects than its been historically.

The old cycle was "get kit, get software, learn how to install software, install on kit", this has recently been improved by developers doing everything locally but its been a right pain in the arse making sure that everyone has the same dev configuration, and putting things like Oracle on the machine just makes it run slower even when you aren't using it. And when you screw it up and have to do the uninstall re-install cycle something always seems to be left behind.

A virtual machine environment changes this. Instead of everyone installing an application server you just have a single virtual machine image that everyone can copy. Mess it up and you just pull down a fresh one. Running virtual machines locally only means that people can be just as effective at home as at work and you aren't having issues with someone else killing the box you are working on.

So if you are looking at upgrading your development hardware, or want to build a case around it I'd heartily recommend looking at things like VMWare Server, Xen, Parellels or Microsoft's Virtual Server as an integral part of those solutions. There are already off the shelf images available and within a project or company environment you should look at establishing your own.

So rather than in future having some poor sap having to work his way around the different developers to keep solving lots of minor config problems you can have that person set up the "right" configuration and then have everyone download it.

Some recommendations

1. For Server VMs keep the network connection local
2. Don't worry about "slow" these are single user instances so keep it minimal
3. Memory is king, 2 GB is the minimum amount you should be looking at
4. Servers = Headless, you don't want developers dealing with these directly if you can avoid it, these are remote deployment boxes
5. Images are disposable, don't worry about fancy OS support functions, its bare bones stuff
   

As core counts and memory goes ever higher and virtualisation becomes ever more effective (Parallels running windows on one 2Ghz core was more than twice as fast as windows native on a 1.4Ghz Celeron M machine) then this really enables us to change the way we develop.

Now there is the licensing question of course....

Technorati Tags: Virtualization, VMWare, development,SOA, Service Architecture