Extreme transaction processing (XTP) has limits that have nothing to do with its 500+ transactions per second performance.
The limits are in its applicability in applications, which may benefit from grid technology, but may not require extreme processing, says Mike Piech, senior director of Oracle Fusion Middleware.
SOA has had a bit of a rough summer. The Best and Brightest of the SOA bloggers have publicly ruminated long and lamentably on SOA’s future. There has been a bit of SOA fatigue in evidence. Could it be because many SOA projects are ready to roll out and some people want to be elsewhere when one or two implode?
SOA fatigue may be traced to aspects of SOA that people have sometimes rightly described as bloated. For SOA repositories and SOA governance the jury is still out. Continued »
Extreme transaction processing (XTP) gets down to business in service-oriented architecture (SOA) applications at AbeBooks.com, a Canada-based online bookstore, profiled in a SearchSOA user story earlier this month. The marketplace for books is using Oracle Coherence, a distributed in-memory data grid designed for XTP environments. A product of Oracle’s purchase of Java performance specialist Tangosol in 2007, Coherence automatically partitions data in-memory across multiple servers.
The Web wins, says Nexaweb’s CTO Jeremy Chone analyzing what happened with the ECMAScript working group Harmony decision announced earlier this month. “This is really good for the Web.”
Chone’s take on this can be found on his blog.
Former BEA customers, who may be unhappy with Oracle Corp.’s plans for WebLogic as its main service-oriented architecture (SOA) server, are targeted by Sun Microsystems Inc., which today announced a migration program for its JavaCAPS SOA platform. Sun is touting the lower price and open source status of JavaCAPS for former BEA customers looking for an alternative to the Oracle version of WebLogic, said Ashesh Badani, SOA director at Sun.
What’s in a name? Grid computing and Cloud computing advocates will soon be asking this question. Growing out of academic and open source software efforts, the Grid was represented as a virtually distributed architecture where vast computing nodes worked on jobs as needed. Grid was an outgrowth of Utility computing. Both terms were efforts to find analogies in the electrical power industry for hardware-software combos in the world of distributed computation. Grid never quite caught on. Continued »
Microsoft Nick Malik recently blogged on “Inside Architecture” about features that would have to be included in a comprehensive framework for enterprise architecture.
There would have to more communication and sharing between models, he writes. A published taxonomy is another recommendation that would particularly benefit smaller businesses.
Like most MSDN blogs this comes with a disclaimer. This is not the corporate line, necessarily. But, with the company’s moves toward OSLO model unification, Malik’s thinking on EA may have special interest.
Some of the challenge to architects these days comes not from the server side where so much integration effort has been placed, but from the client side. There, Ajax has arisen to improve users’ interactions with multiple application services.
But, as Richard Monson-Haefel told SearchSOA.com’s Rich Seeley, the unending proliferation of thinly supported open-source Ajax frameworks may cause architects for proprietary RIA-alternatives to Ajax. The long-time Burton Group analyst recently took a spot in the Curl brain trust.
Rich writes of his conversaion with Monson-Haefel in How to sort out Ajax and RIA frameworks. Monson-Haefel cites Curl, Flash and Silverlight among RIA choices some individuals are now considering. What do you think?
Last week we at SearchSOA.com ran a story about how ESBs aren’t as interoperable as users might expect them to be. The story prompted a response from StrikeIron CEO Dave Linthicum, basically wondering if the bigger problem here is bad architecture. He wrote:
Call me crazy, but would it not make more sense to have a centralized plan as to what the SOA should be, based on the requirements of the business, versus people dashing out and shelling out the dollars for an ESB for some one-off tactical reason, or more likely just acting out of reaction to the hype? Now, you’re left with a dysfunctional mess that’s not easily corrected, and clearly costly.
Joe McKendrick over at ZDNet picked up on that and put together a brief history of ESB criticism. Linthicum’s blog entry also drew a lot fire down in its comments section (be sure to check them out as iTKO’s John Michelsen, the interviewee in our original article, makes a few points on the unavoidable nature of multiple ESBs). The response in fact spurred Linthicum to write a follow up entry addressing some of the critics of his first entry. After pointing out many of the dysfunctional things he’s heard over the years, he wrote:
[W]hat I’m asserting is that there has to be some architecture forethought behind dragging any technology into the enterprise, and I suspect that’s not occurring.
To be fair, he doesn’t suspect it. He knows that’s the case. We all know that’s the case. As Software AG’s Miko Matsumura put it in another article we ran last week, “People are addicted to messed up IT.”
Anyway, Linthicum finished his latest post with a request:
So, in the spirit of having an open mind, send me your reasons for leveraging multiple ESBs, and why that’s a good approach for your enterprise architecture. Also, while you’re at it, make sure to send me the reasons you’re using an ESB to begin with: your requirements and the reasoning behind the solution. I won’t post them unless you say it’s okay.
It’s an interesting topic, so make sure to send Dave your reasons, if you’ve got some. For my part, I know a lot of people who despise ESBs. During one interview I did with an analyst back in 2005, he referred to ESBs at “methadone.” This was actually praise for the ESB, making the case that it was better than EAI. Yet I know others who just as adamantly argue that at some point you’ve got to implement a service or pull together applications after a corporate merger, and at that point you will find yourself wanting an ESB.
Earlier this year, I actually did a podcast with Mulesource CEO Dave Rosenberg about why he maintains that enterprises will need to accommodate multiple ESBs inside their SOAs.
I would argue the larger point here, and this is where Michelsen was focused in the original article, is that multiple ESBs are a fact of life. No matter if it may be sub-optimal in terms of architecture, a good architecture should be able to tackle this kind of problem, or at least good governance should help ameliorate it. Mergers and acquisitions will happen. You will need to combine services with outside entities. Different divisions will buy disparate products, even if they shouldn’t. This doesn’t even touch on technology creep from the open source arena.
So it’s really two questions. The first is do you even need one ESB let alone many? It’s a fair question and one that every end user ought to put serious thought into answering. The second is, how do you deal with multiple ESBs in your infrastructure? Because no matter how you answer the first question, you will need to manage this situation for at least the near term.
We’re officially into the dog days of summer, that time of year when you’re mind strays to thoughts of cooling off in a body of water. As it turns out, we’re also into the dog days of many SOA implementations.
A recent Burton Group study found that many SOA initiatives have stalled, mainly due to an inability to involve the business in the effort. In a more general sense, stalls are to be expected in any 20-year initiative. Faces change, acute problems arise, the funding pipeline temporarily goes dry. Surely you didn’t expected that achieving enterprise agility, automated business processes and streamlined data access would be a quick or easy process.
If you’re fighting through a corporate lull or battling your own ennui, take heart – you’re not alone. During a long haul you will need to take some rest stops and SOA is an extremely long haul. Here’s some thoughts from Burton Group’s Chris Howard concerning SOA fatigue:
- “You can build something that is absolutely spot on perfect and it will still be wrong.”
- “Reusability is always over-promised.”
- “What do the executives care about? They care that the SLA holds and they don’t care how you do it.”
- “SOA fatigue is setting in because SOA success is tenuous, but when SOA succeeds, it really succeeds.”
- “What does it mean to be 100% SOA compatible? Is that like good fiber or something?”
- “SOA needs to be part of something bigger and if it’s not, then you ought to ask yourself why you’re doing it.”