Lustratus LiteBytes

Archive for the ‘Web Services’ Category

I was on a call this week with Platform Computing, a well-known software vendor in the high-performance computing (HPC) world of grids and clusters that is now trying to make the leap to the Cloud Computing market.

Platform Computing has a strong reputation in the HPC world, selling software that helps manage these multi-processing environments, but it is keen to expand its market coverage and open up new opportunities in more general areas of IT, and it has selected the Cloud Computing marketplace to help it achieve these diversification aims. At first, this may seem odd, but a little thought quickly shows that this is not nearly as big a leap for Platform as it might at first seem. After all, internal clouds almost always involve virtualization, and handling the management needs of a virtualized environment is very much up Platform Computing’s street.

But for me, the real nugget that came out of this briefing was an interesting distinction that helps improve understanding of Cloud Computing and its relationship to Virtualization. I meet a growing number of people who have heard about Cloud, but do not see the distinction between Cloud and virtualization. While there are a number of ways to look at this distinction, as I discussed in my Executive Overview to Cloud which Lustratus offers at no charge from its web store, the discussions with Platform brought another one that I think is an interesting take. The Platform position is that virtualization solutions by definition only make virtualized resources available for usage. Its Cloud management software differentiates itself from virtualization by offering heterogeneous access to resources – that is, Cloud-based access to resources that have already been virtualized AND ones that haven’t. I think this is a useful distinction to keep in mind when looking at data centre strategies.

Steve

I have just returned from a couple of weeks around and about, culminating in presenting at the Integration Consortium’s Global Integration Summit (GIS), where I presented the Lustratus ‘BPM Sweet Spots’ paper.

One message seemed to come out loud and clear from the conference – pragmatism is the watchword for 2009.

There were two other analyst presentations apart from the Lustratus one, and I was surprised to see that both presenters pitched a message along the lines of ‘you will never succeed with SOA/Integration/BPM unless you get all the strategic planning and modelling for your enterprise done first’, combined with a suggestion that the presenter was just the resource to ask for help! This contrasted sharply with my own presentation of choosing tactical targets for BPM rather than going for a strategic, enterprise-wide, fully modelled approach.

I was wondering if I had read the mood wrong in the marketplace, but then the eight or so user case studies all proved to be tactical strikes for specific business benefits rather than the more extensive strategic approach more common a year or so ago. It was nice to be vindicated – it looks like 2009 really IS the year of pragmatism and short-term practical considerations.

Steve

Morgan Stanley was recently talking about its major SOA investment spanning the last 18 months.

Implemented in its Global Wealth Management division , the justification for SOA was to give advisors and clients an integrated view of more accurate information, more quickly.  As with most SOA projects of this scale, SOA isn’t the whole story.  Morgan Stanley had to first upgrade the network infrastructure to give its branch network the bandwidth required, then implement SOA on top and finally use ETL to convert the data flowing through their service bus into the dashboards the advisors look at (and a customer portal).

Interesting aspects of the coverage include:

• The programme was a strategic initiative to make this division competitive now and into the future.  Technology is simply the enabler to that goal.
• A best of breed approach was taken to the technology: IBM for the SOA layer, Informatica for the ETL.
• Web Services were used extensively (In the drive to distinguish between SOA and Web Services, it is easy to dismiss Web Services.  They can and often are part of the SOA technology stack)
• The project included major rewrites of existing applications – to consolidate where possible and also to update so that they could be plugged into the SOA framework.
• The common problem of changing the development culture away from write-it-all-ourselves was stressed.

Ronan

Summer seems to be a time for reading through that huge pile of interesting articles and magazines that you can only find time to look at on vacation.

On flicking through my own mountain of stuff, I came across the Q2 edition of Financial-i, a magazine targeted at the Financial Services industry. One point to jump out at me was a comment from Paul Joynt of Nordea, a Scandinavian finance house.  Paul was pointing out that SOA does not necessarily solve the problems associated with legacy integration.

The article, ‘SOA – is it worth the effort’, is available from the Financial-i site if you register, but Paul comments that covering a legacy system with a wrapper “so it looks like what you want” still leaves problems with the next level of change, because “it’s only a veneer”.

I think Paul has hit on an important point here. Different vendors in the SOA space have different approaches to addressing the problem of integrating legacy systems. Some will simply ‘hand off’ the request for legacy information to a tool from the legacy supplier – in the case of IBM mainframes this might mean using WebSphereMQ as the bridge, for instance. Others might approach the problem in some sort of screen-scraping or other interface simulation approach, where the legacy application is fooled into thinking it is running in its normal mode of operations. Yet more may generate code-based wrappers for each individual need, to be executed whenever a particular service is required.

To me, this all sounds too much like veneer in Paul’s terms. Although this might address immediate needs, future changes will continue to generate substantial additional work and the generation of more and more ’special-case’ code and wrappers.

Instead, the best of breed legacy integration solution should embrace SOA and integration rather than try to fool it with wrappers designed to seal off the legacy world from the outside. Legacy integration should be about making the legacy system a full and active participant in the service definition and execution. For example, orchestration should be possible both outside and within the legacy environment. Services should be built with full participation from both sides. By taking this approach, the best of breed legacy integration tool will ensure that future changes will become easier, quicker, cheaper and more reliable.

For more information on the whole subject of legacy integration, specifically in the case of mainframe systems, Lustratus offers a free paper on the subject.

Steve

I was intrigued to discover a discussion paper from the University of Southampton in the UK about how SOA is helping the scientific community.

The paper, entitled ‘A Collaborative Orthopaedic Research Environment’, describes how SOA has been used to enable a Virtual Research Environment for orthopaedic researchers to collaborate in the design, analysis and dissemination of experiments.

What I found most interesting were the reasons for using SOA as the base architecture for this environment. The key objective, based on input from the specialists who will use the system, was to provide an easy way to share scientific data and results from collaborative research. However, it was deemed essential that the system could also evolve based on the changing requirements of the user community. One example of change that the paper gives is that of knowing which of a wide range of protocols will be followed for a particular clinical trial. Not only do these vary considerably, but it appears they are also susceptible to changes in regulations.

The solution decided to utilize a coarse level of services, essentially using just four – to manage the trial-related data, analyse it, submit and disseminate related research articles and support discussion forums. However, through the reliance on SOA, these services are flexible and extensible, making it much easier to address the changing needs of this particular scientific discipline. In addition, the services are reusable, and some could therefore be usable for other scientific areas.

It’s good to see SOA being used to effectively address clear user needs in this way.

Steve

Microsoft recently made two SOA related announcements:

The next version of Biztalk will have a SOA veneer (commented on by Joe McKendrik ) and more interestingly Microsoft will lauch a  Software as a Service(SaaS) SOA offering.

I blogged previously about how SaaS itself increases the requirement for integration as multiple SaaS based applications must be integrated together.  This has the potential to derail SaaS initiatives – particularly in smaller organisations without sufficient IT skills and budget to deliver on an integration strategy (SOA based or otherwise).

Microsoft is taking a different angle on the SOA and SaaS story by focusing on cross-department integration and attempting to solve particularly painful aspects of the problem with SaaS offerings that will be called collectively Biztalk Services.  In essence, each service hits a specific integration issue which would otherwise require a potentially large investment in infrastructure.  The first two are:

• Identity: allowing management of users across departments and organisations and
• Connectivity: providing enterprise style message (pub-sub for instance) across the internet with appropriate security – thus making ‘safe’ exposure of a SOA service across multiple organisations.

Their picks of identity and connectivity for the first two services is smart as both are inevitably part of any cross-departmental SOA project.  The strategy is also smart as it neatly leverages where Microsoft is already strong (at the department level and in SMB) and where the SOA skills shortage is hitting hardest.

As such I don’t think it is necessary to look at this announcement through Google-tinted glasses and disagree with Ron Schmelzer of Zapthink who is quoted as saying:

“I think Microsoft is really rethinking a lot of their server infrastructure because Google is a competitive threat,”

Microsoft is not doubt thinking hard about Google but it is only fair to point out that this is not a market where Google is relevant as yet and it is not a new departure for Microsoft or even Biztalk:  Biztalk was originally about internet-based integration as this article from 2000 shows.

Ronan

OK, I think it is time to stop all the WS-Madness.

Web services standards have become a complete joke. As far as I can see, there are now at least 70 (seventy) web services standards and drafts – more than anyone could humanly want, and enough to create chaos, and completely negate the advantages of standards in the first place. Standards are supposed to increase choice, but with so many the likelihood is it will actually REDUCE choice (do you support standards 27, 39 and 40? no, I support 23, 42 and 63 though, any good?).

So, who is to blame for this debacle? Well, the blame is pretty evenly spread. Perhaps the most obvious target is the vendors, who have unashamedly used WS standards as a battleground to try to create differentiation from competition. So, by creating a standard that fits in with ones own design, it is then possible to use this as a reason for rejecting other players. However, vendors are easy targets – but are they really the villains here? After all, you could argue that they are just doing what they have to do – trying to compete, to win business and pay their employees / shareholders. The next obvious choice is the standards bodies themselves. Sadly, there are many ‘professional’ standards body members who get intellectual kudos from defining standards – whether they are worth anything or not. But even this may be missing the point.

Perhaps, instead, blame should be turned on users. The vendors have stepped in because of two things – the opportunity created by the desire for standards in the SOA space, and the vacuum resulting from the failure of users to take an active role. Similarly, standards bodies have leapt into the void because in a way they have to generate standards to have any worth in the world. But the real accusation is that the standards are rubbish – most are immature, many are useless or pedantic. In other words, they do not add value for SOA users and implementers. And isn’t this a case of users getting what they asked for? If users don’t want to get involved to ensure the RIGHT standards are created, that really mean something to users, then they cannot complain when others jump in to fill the vacuum.

My advice to users on web services standards is to ignore all but the important ones – SOAP, WSDL, WS-Security, and maybe WS-Addressing although this is not as mature as the other three. Then take a more active role to ensure these standards mature into what you actually NEED.

Steve