Some initial teething problems, but the 'real' Illuminatus blog is over here:
http://ronanbradley.typepad.com/litebytes/
While the Illuminatus web-site is here...
http://www.illuminatusresearch.com
If you check this blog out or have the rss feed, look at the new blog. Both Steve Craggs and I will be blogging and will attempt to start up some discussion between the two of us and whoever else wants to comment.
Ronan
I won't be using this weblog again but if you want to find out what I am doing then check out the 'real litebytes' at:
http://ronanbradley.typepad.com/litebytes/
Ronan
I attended InfoSecurity in London this week - huge show for companies involved in all aspects of information security. Not something that seems to relate to SOA at first glance, but it turns out a number of vendors are waking up to a growing concern in SOA ranks - that web services may be a gift for hackers.
Apparently, the problem is all down to SOAP. Security companies produce loads of smart software and hardware that intercepts internet-based communications and looks for various types of threat signatures, for things like viruses, spyware, adware, trojans and general unwanted intrusions. These tools analyse traffic, but the problem is that few, if any, recognize the SOAP protocol today. So typically the SOAP packets are allowed through because the security software is blind to the information contained in them. On top of this, SOAP messages are often encrypted, making the problem even worse.
This thought is proving to be quite disturbing to a number of major companies. The issue is that in an SOA, web services provides a neat way to make back-end applications accessible to other parts of the business, partners or even the outside world, and what is more, the back office operation is where a lot of highly confidential, mission critical and sensitive information resides. So, if there is a way for someone to sneak in under the radar provided by network security tools, this represents a measurable risk that users feel must be addressed.
As far as I can see, there may be potential for exposure here, but I am hard pressed to think of a specific example of how this hole might be used maliciously. But then, there are a lot of extremely smart hackers out there who love a challenge! My view is that, regardless of how real this fear is, the first companies to come up with a solution to this perceived exposure will profit substantially based on a strong element of FUD (Fear, Uncertainty and Doubt). Perhaps what is needed is the SOA and netowrk security vendors to get together and start talking each other's language.
This blog is changing again - I won't say anymore about it or Illuminatus beyond saying watch this space.
Ronan
I am now going to focus my blogging on my new blog on ebizq.net called "Roads to SOA". I will keep this live but only post occasionally.
I continue to be surprised at the lack of comment around the change in strategy announced by iWay a couple of months back and now followed through with the release of its Enterprise Integration Suite. For those of you who don’t know who iWay are: they are the division of Information Builders, which had focused on selling adapters to a multiplicity of applications and technologies. In particular, they have a wide set of reseller/OEM partnerships (as can seen on their partner page) with many vendors who are also in the business of selling ESBs/Enterprise Integration Suites such as Sonic Software, Software AG, Metaserver, In terSystems, Cordys as well as big boys, IBM and Oracle.
Lets take the example of Sonic, if you go to their webpage you can see a very impressive list of adapters. If you select one, say for Siebel, and look at the datasheet – guess what: it is the iWay adapter. In fact most if not all of the 250 claimed are actually iWay adapters.
I am sure company spokespersons from iWay and its partners will say the new announcements from iWay doesn’t change anything – trusted partner blah blah blah. This simply doesn’t wash, no sales person from Sonic or Software AG or the rest is going to feel comfortable introducing a competitor’s product into their accounts as part of their core value proposition. This leaves all of these vendors with a big problem with their current value proposition: no out of the box adapters (one of the headline features of most ESB offerings) and one which they can only address in three ways:
In defence of option 1, while it will take time and money, there are probably not a huge number really needed (who actually wants a Candle Roma or Digital Standard MUMPS adapter these days?).
There are of course two bigger questions:
And finally, what does this mean for the end-users who may be considering buying an iWay adapter from Sonic Software, Software AG et al? If your project is more about the adapters than the bit in the middle, I can only recommend going direct to iWay. If the reverse is true, I feel that you must treat the adapters with caution and probably look for alternatives (perhaps even custom coding the few you need).
The Enterprise Service Bus: Ugly Duckling or Beautiful Swan
The debate on whether the ESB is going to be a short-lived fad has recently reignited across a number of blogs. I say debate but in fact the majority of commentators seem to be on the short lived fad side. While I am no longer associated with an ESB vendor, I must admit to retaining a certain belief in the term – not because I think ESB is the right TLA but because the products in the category deliver real functionality that solves real problems in SOA deployments.
Lets start on a positive note by saying that I totally agree with David Linthicum’s final conclusion in his recent blog item ‘Why “ESB” will be Dead in a Year’ when he says
Focus on your own requirements, and what the product does specifically to meet them. It matters not if it’s ESB, EAI, B2B, SaaS, or EIEIO Look past the marketing at what the product does, and draw your own conclusions.
However, when you examine his objections most are related to the supposed vagueness of the term and tendency of marketing departments to hype which is rather contrary to the title of the piece. (I also notice that of the three items he references as knocking the ESB – one was authored by him at another of his blogspots and a second included quotes from him. These multiple manifestations further reinforces my impression that David is rapidly becoming the SOA blogosphere’s equivalent the Matrix’s Agent Smith).
A second knock on the ESB term is well expressed by Jim Webber and comes down to the view that ESBs are used to make up for poor service design.
In this item, I will attempt to knock-back these objections…
Objection 1: The ESB is such a vague term it is worthless
It is certainly true that if you were to take all the products which claimed the badge ESB, you would see a lot of diversity of features and functions. However, this does not correspond to vagueness per se. So why is the ESB perceived by some as vague?
One factor was that the initial definition from Gartner was heavily influenced by the Sonic product of the time and hence was particularly minimalist, and left space for products to spuriously be given the label ESB. It really didn’t cover much of the features which would now be regarded as necessarily in any ESB worth its salt (for instance business process orchestration). The strangest part of this original definition for me was that an ESB required support for only “limited transformation” – a little surprising as a limitation for something that claimed to be enterprise grade. However, the vendors and more importantly the analysts have moved on considerably since then and the Forrester Wave on the ESB published late 2005 had a very precise and extensive set of functionality requirements.
The second vagueness related accusation against the set of ESB products is that they are so different from each other. To me at least, this is in fact not so surprising. SOA is being used to solve a broad set of problems across many industries. It is not surprising therefore that products reflect this diversity. What will be interesting to watch for is the refinement of the common base of functionality which any ‘decent’ ESB must have. This is a work in progress as users get to grips with their SOA rollout and ESB-based solutions in parallel to analysts developing eco-systems and frameworks.
However, it is only fair to accept that David is also right to a degree here: vendors are rebadging their old products in an attempt to give them some new life. But this is always the case with a sexy new product category and to my mind not the main reason for the diversity. And finally, no I don’t especially like the term itself and in particular the wild use of the letter E for enterprise in this (and so many other software industry terms) – if government agencies use these products do they become ASBs? – however ESB has stuck and so long as we all know what the product is meant to do, we should just put up with it.
The ESB is aspirin for the headache of badly defined services
To quote Jim Webber :
But the solution is not to build services in such a crummy way, not to deploy more middleware to hack round the problem;
The "age-old problem" of putting smarts in your endpoints is exactly what makes the Internet work. Putting smarts in your endpoints is good, putting smarts in your network is not.’
I think Cisco and others may not agree with this view of the internet – the internet works because of the standards and a lot of smarts in the routers in the middle, not to mention the smarts in DNS and the rest of the internet infrastructure.
However, if I extend the comment to the web which may have been Jim intention, there is a view of the SOA world which objects to the concept of intermediaries believing instead that the service definition if properly defined is sufficient for all SOA-based integration purposes. The comparison to the web-browser model is interesting because I would argue that it is a very specialised (all be it very popular and wide-spread) integration model. The clients (i.e. browsers) are dedicated consumers of the services and there is a highly evolved set of standards around this use case. While the web servers are certainly smart, they are operating in a particular model: a client connects, interacts, disconnects. The clients are also smart, but similarly limited: typically they interact with a single web server at a time.
This is certainly one style of integration – in fact I would describe it as a substyle of a composite application. Brenda Michelson of the Patricia Seybold group defined this and the alternative flow style rather well in her “Service Oriented World: Cheat Sheet”.
The two primary styles of SOA used in business solution development are composite application development and flow. In composite applications, the user interaction drives a request for one or many services. Most of the service invocations are synchronous in nature. A composite application typically serves one business domain. Composite applications are often delivered in a portal.
In flow, business process and/or events drive the service invocations. The service invocations are a mix of asynchronous and synchronous; however, the overall flow is usually long running and asynchronous. A flow typically crosscuts business domains and often extends outside of the enterprise.
The composite application style works well for the problems it solves (i.e. portal based user driven integration) because the client is built to use the services. This means it can be written to deal with the tricky part of using a service: inconsistencies between the information model exposed through the service and the consumers information model – if the service definition assumes data submitted in this format, write some code to submit it in that format.
Unfortunately with flow style SOA the world is very different as each business process will span potentially many systems and organizations (and hence technology and data models). For instance, the processing of a purchase of a particular financial instrument by an investor must flow between organizations (the buy side bank to the sell side bank and back), may cross many departmental boundaries (to deal with the components of the derivative such as equity, equity derivative, credit etc) and must integrate into the risk and regulatory compliance units.
In this environment, there is a clear requirement for potentially multiple entities to control the flow (orchestration or choreography), and to bridge between the information models of the different departments and organizations (mediation) as well as ensuring it is all done in a controlled and auditable fashion (governance). In fact, the key components of a modern ESB. If there is no ESB, I would somebody to explain how all of this is done by the smart end-points! Furthermore, I would to understand how this becomes possible when we reach SOA Nirvana when some believe the ESB requirement melts away.
And so, what does all of this mean
To return to my title for a moment, is the ESB an ugly ducking or a beautiful swan. Unfortunately, it is probably the ugly duckling. ESBs are there because the real world integration - SOA based or otherwise - isn’t beautiful and clean. It is full of compromises between the way we wished the world was (full of consistent data models and simple business processes) and the way it is (every changing messy complexity). Unfortunately, transformations into beautiful swans only happen in fairy stories and scary reality television shows.
I am delighted to kick off this blog and start with the news for those who know me from my previous blog that I am no longer with PolarLake where I was CEO for the past 4 years. At the end of last year, I decided that it was time for a change for me and a good time to leave with PolarLake in its strongest position ever - having recently closed a funding round and at the end of its most successful year to date in terms of revenue, with a growing number of large and repeat customers.
However, I will be maintaining and developing my focus on business integration technology and more importantly how and even if SOA and ESB will work out over the coming years. It is so often the case that as a technology or approach is hyped its agenda moves from the credible to the incredible until it falls back to what it turns out to be good at or simply fade away entirely (anybody for some artificial intelligence?). I believe that 2006 will see the start of turn in the tide as limitations in products and standards as well as shortages of expertise in both vendors and end-user organizations will lead to failures being highlighted as often as success. However, this is no reason to be downcast – lets not be naïve to think that SOA has to solve all known human problems to still be a worthwhile development.
Expect this blog to focus on the issues of adoption, technology and standards around enterprise integration. I also hope to cover relevant technology news as it breaks – but on no accounts will I be writing about my kids, my vacations or the cool digital toys that I am struggling to use!
Recent Comments