Archive for July, 2008

Client Side Session Management (part 2)- Sharing is good

July 31, 2008

In my first article we covered the issues of server side session management and the benefits from a server perspective of session data being managed client side within a browser. These benefits are mainly technology related, but what about the user benefits? Yes faster more responsive applications can be achieved with client side session management, but from a user perspective the ability to share data across applications would be very powerful indeed.

The concept of being able to share data across disparate applications is not new, indeed as a windows programmer I’ve gone through the journey of DDE (dynamic data exchange), OLE (Object Linking Embedding), COM etc… However windows also had other mechanisms such as Global Atoms (anyone remember those ?) as well as traditional approaches like local databases or files.

However a browser based model is more difficult because of the sandbox security model. A server based solution does exist in the Java world this is the area of WSRP and Portlets. WSRP allows portlets to publish data to other portlets using standard interfaces. So if you had a window with a directory of your contacts listed, you might click on a name and your other windows (portlets) would respond by bringin back data about the person you clicked on.

Again however, if only browser developers would open their eye’s to client side session management, we could have very dynamic applications WITHOUT portlets and the server side overheads associated with portlets. (Remember a portal view of 5 portlets, means 5 times the number of sessions being managed by the server – hmmm you thought you had redundancy and performance licked until you deployed portlets ;o)

So how could this be done? I’m sure there are a number of ways, but if it’s been done before and worked well then I’m all for plagarising. Global Atoms ;o) Basically you should be able to define a global variable and provide a publish/subscribe model for that data item. This then would allow you to share data across browser applicatons (a bit like Google auto fill, but with application definable fields).

 The consequence? We reduce carbon footprints whilst creating more dynamic applications.


Digg!

Convergence

July 25, 2008

The headlines scream with news of ‘frenzied demand’ and ‘swamped retailers’.

 

Apple’s latest version of its converged mobile device the iPhone has just hit the UK shops – and customers are literally fighting to get their hands on a device. So, why is there such demand?

 

A healthy dose of media hype helps, of course. Create a big enough buzz and people will start to become curious.

 

But beyond the build-up, demand for the iPhone is representative of a step in a crucial direction: convergence.

 

Empty your pockets. As well as your keys and wallet, there’s a good chance you carry a collection of digital devices, such as a phone, handheld computer and other access devices, including a travel card or security pass.

 

Carrying such devices can be a weighty task. But a helping hand comes in the form of convergence – an approach to mobility that is helping users integrate devices and access information on the move.

 

Devices, such as the iPhone, bring together mobile networking and computing to offer the user a broad series of applications.

 

Users are keen to buy into converged technology, even as the effects of the downturn continue to bite.

 

Sales of mobile smartphones are expected to grow by as much as 14 per cent this year, according to the Consumer Electronics Association.

 

Convergence isn’t just confined to mobile handsets. Take the area of payment card systems, for example.

 

Barclaycard runs a contactless card technology that allows people to purchase goods in shops and to buy Oyster units for travel on the London Underground.

 

For even more remarkable examples of convergence, turn to the kitchen and take a look at the Whirlpool Polara. The kitchen appliance combines the heat of an oven, the cooling of a fridge and the smart approach of contemporary technology – so that a meal can be kept fresh and cooked in time for dinner.

 

Now I just need some willing provider to converge a smartphone and a payment card system. Then the weight will be really off my pockets.


Digg!

Client Side Session Management…

July 18, 2008

Ok this is an old hobby horse I’ve reeled out many times, and now that I’ve got round to starting a blog what better place to find a permanent home for this old equidae.

The traditional way of managing sessions is on the server with the application container managing session keys/data. As a front end developer your job is simply to populate the session data as it is capatured on screen, the application container does the rest for you. The application container should offer different mechanisms for replicating session data across servers, thus providing session failover. It should also optimise the storage of the data itself, and manage the session keys with it’s own policies for clearing out dead sessions.

The problem with this model is that it is simply not that easy. Some of the issues that need further consideration are: Memory optimisation, Long vs Short Running sessions, Server Redundancy:

When storing data in sessions, the data element is normally given a name, generally this is something meaningful that a developer can use to make code more readable. However these name themselve take up memory. Whilst this may not seem a huge issue with the amount of memory in servers these days, we’ll see later in the post why optimising memory for sessions is necessary. So one improvment you can make is to implement hashing to reduce lengths of names used in code. Another technique would be to use compression for the actual session data especially for large free text fields.

Generally there are two types of sessions long running or short sessions. Typically internal applications such as call centres will have users that log-in in the morning use an application all day, and log-off at the end of the day. Such applications if not designed efficiently often do not release session data during the session, this can have the issue of builiding up huge memory requirements per user of the application. Prior to memory depletion, performance degradation will be the first issue as memory is swapped in/out of disk, followed by out of memory server crashes. Hence developers need to consider what memory should be held and when to release this memory. Short running sessions with mass users e.g. shopping sites, tend to have less per user storage requirements but many more users, creating a large memory requirement overall. In this scenario identifying dead sessions is paramount to reduce memory redundancy. Other optimisations include identifying session data that is used not per user but globally across all sessions, and caching one instance of that data rather than load it per user.

So it is for reasons like the above why client side session handling make so much sense, if only it was supported as standard by the browser rather than having to use hidden fields. Quite simply client side session management is a means of keeping data in the browser rather than on the server, therefore reducing the memory requirements and extra processing that an application container has. It would not only reduce the cost of the server you’d need it would also improve performance of the client application also, more so than the use of Ajax.

I can’t think of any downsides to this approach whilst the upsides are huge. What do you think?


Digg!

The Front Tier Of SOA – building from the front to back

July 16, 2008

Building from the front to the back…Most discussions about service-oriented architecture (SOA) concentrate on back-end issues, such as middleware and integration. Such a healthy debate fails to recognise one key concern – your users will not make the most of SOA if they cannot access information.

Unfortunately, a failure to recognise the importance of the front-end is not confined to industry debate and many SOA implementations actually focus on the back-end, rather than the user interface.

The result? Initiatives are created with the technology in-mind, rather than concentrating on the demands of the user. And in such circumstances, your SOA system will not be flexible enough to meet future changes in demand.

Posthumous alterations can be complicated and have a serious impact on your business. So focus on a number of key issues as you develop your front-end: interaction, compliance and standards.

Have a strong awareness of how users interact because new forms of presentation are likely to be crucial to your SOA strategy. Mash-up applications, for example, can allow business users to create new and useful combinations of information and researcher Forrester estimates spending on mash-ups will reach $700m a year by 2013.

You will also need to prioritise governance. Analyst Butler Group recently suggested that failure to address business rules and security policies at the design stage can lead to complex change management at a later stage.

Finally, think about the types of formats and frameworks you will use to help guarantee a top-quality user interface. Make the wrong choices at an early stage and you could restrict further development opportunities at the front-end.

This three pronged approach shows that sometimes it makes sense to concentrate on the presentation details before you look at the foundations. Such a grounded approach to service-orientation can ensure the demands of users are met.

 


Digg!

End of development or end user development?

July 9, 2008

Don’t worry programmers, coding is here to stay. However should all development be done by programmers, I’d argue that business applications should be developed by business users with specialised tools provided by programmers. And there is nothing new about my prophecy, it is aligned with a trend called End User Development (EUD).

 

End user development is not the end of the road for the IT department

 

Allowing non-professional developers to create or modify technology resources sounds like an IT manager’s worst nightmare.

 

After all, giving control of development to untrained users is likely to involve complicated logistics. And who needs programmers if the business can develop its own code?

 

IT managers should chill out. End user development (EUD) – the activity of allowing users to create code – is happening and will continue to increase. A recent US-focused survey estimated the number of end user developers will hit 12 million by 2012.

 

The good news for firms fearing the transformation is that EUD can help cut costs and boost efficiencies across a wide range of technology areas, such as web design, collaboration and modelling.

 

Non-IT professionals will become involved in code development for a number of reasons.

 

Sometimes unsuspecting employees create ad hoc solutions for specific business problems, such as macros in Microsoft Excel. On other occasions, end users respond to gaps in existing technology provision and search out new resources.

 

You should get involved now and understand business needs around EUD.

Create policies to help ensure compliance is prioritised and programming errors are minimised.

 

A group of academics from the Manchester Business School are already analysing the potential benefits of EUD and IT managers can discuss their own experiences at: http://eud.survey.sgizmo.com

 

You will probably find that giving non-IT professionals an opportunity to develop resources offers a route to smarter technology management, rather than the end of the road for the IT department.

 

So, be brave and investigate the potential of end user development; because if you don’t, your competitors soon will.


Digg!

Dharmesh Mistry, CTO/COO – edge IPK

July 8, 2008

 

We’re witnessing technology’s coming of age: from the era of business automation to the era of business agility’

Dharmesh is co-founder and Chief Technology and Operations Officer for edge IPK. At edge IPK Dharmesh leads product development and professional services. He champions thought leadership about the presentation layer (user interface) within SOA. This blog focuses on key areas of his thought leadership. 

Since 1996 Dharmesh has successfully pioneered some of the earliest online financial services solutions in the UK, including Multi-Channel Internet banking for The Co-operative Bank (internet, PDA and Kiosk) and Woolwich Open Plan Services (Internet, Call Centre and Mobile) plus Internet insurance sales for Eagle Star Direct.  At the same time, Dharmesh’s team has re-written the online rulebook in terms of achievable delivery times and pioneering solutions.

 

Dharmesh started his career at LloydsTSB and moved onto NatWest, developing leading edge IT solutions and providing business consulting.  He soon gained a reputation as a visionary, promoting radical ideas for how the banks could use technology to create new business models.  He promoted the idea of franchising (retail brands offering core banking services) many years ahead of its eventual adoption as a commonplace banking strategy as well as pioneering the concept of Single Customer View for LloydsTSB almost 20 years ago.

 

At LloydsTSB, Dharmesh worked with senior management on a business re-engineering project delivering solutions to provide significant business benefit. He then developed workflow expertise with specialist software vendor Centrefile. Dharmesh moved into NatWest Bank where he defined the technology strategy for NatWest’s Card Services.

 

Most recently Dharmesh has been involved in the global deployment of edgeConnect, edgeIPK’s flagship product, for ABN Amro. He is also working closely with Manchester Business School on End User Development and is a key company spokesman on the IT Skills Shortage issue being addressed by the UK Government.

 


Digg!