Java Business Integration
A good introduction to what JBI is about. However I'm skeptical that this is a better way to build integrations especially based upon the author's comment on the canonical document.
Steve Vinoski, writes "All the messages exchanged through the NMR are normalized messages, which doesnÂt imply that all messages are converted to a canonical format. As I mentioned, EAI systems already proved that translating messages into canonical formats can negatively impact performance, scalability, and the ability to further integrate systems with other integration infrastructures. The NMR avoids these Ânegative impacts by treating message payloads as opaque data that it simply sends along to the receiver."
Steve Vinoski, "Java Business Integration," IEEE Internet Computing, vol. 9, no. 4, 2005, pp. 89-91.
Not only have I not seen this performance issue, the canonical format is one of the bigger benefits from inserting an integration layer. Sure things like persisted messaging, async processing etc are nice but at the end of the day if you have tied all of your integrations together without the canonical, what are you left with? A very robust set of point-to-point integrations. Maybe I'm missing the boat here but it seems to violate the principals of abstraction, de-coupling etc. It seems that we are just moving the translation engine out of the middle layer and letting the application(s) do it. Is that really a good thing?
Tuesday, August 30, 2005
Saturday, August 27, 2005
Open source ESB projects Synapse and Celtix contributed
Open source ESB projects Synapse and Celtix contributed
A little more on the ESB and Open-Source. At what point do big companies who rely on mission critical software, start looking at the open-source offerings. Every company is unique in its tolerance for risk. The question becomes what is more risky? Closed systems from a single vendor with no control over end of life cycles or changes in product direction? Or using software from a community effort or small financially questionable company? Not an easy answer I am afraid. Both have their risks and impacts to corporations.
The open-source path. Simply having the source and being able to control your own destiny sounds good but what about in actual practice? Do you have the development expertise to handle the source, make changes? Do you really want to do that? What about support? Is your corporation self-sufficient from support standpoint or do you rely heavily on vendor support? I think the answers to these questions would have to drive your decisions. I think corporations with strong Unix and Java backgrounds would tend to do better here as a start.
Closed vendor path. The benefits here tend to be (but not always) stronger vendor stability and a more robust/dependable support structure. ie escalation paths when things go bad. There is probably a better long term outlook for the software from the vendor and a more well defined plan. The catch tends to be lock-in. The vendor will make decisions on direction based upon their business needs. If their needs and your needs align, very good. If they do not align, you could find yourself with some difficult and costly decisions.
The choices and decisions are not easy ones to make. But every corporation should be aware of the software market and the impact open-source offerings are starting to have.
A little more on the ESB and Open-Source. At what point do big companies who rely on mission critical software, start looking at the open-source offerings. Every company is unique in its tolerance for risk. The question becomes what is more risky? Closed systems from a single vendor with no control over end of life cycles or changes in product direction? Or using software from a community effort or small financially questionable company? Not an easy answer I am afraid. Both have their risks and impacts to corporations.
The open-source path. Simply having the source and being able to control your own destiny sounds good but what about in actual practice? Do you have the development expertise to handle the source, make changes? Do you really want to do that? What about support? Is your corporation self-sufficient from support standpoint or do you rely heavily on vendor support? I think the answers to these questions would have to drive your decisions. I think corporations with strong Unix and Java backgrounds would tend to do better here as a start.
Closed vendor path. The benefits here tend to be (but not always) stronger vendor stability and a more robust/dependable support structure. ie escalation paths when things go bad. There is probably a better long term outlook for the software from the vendor and a more well defined plan. The catch tends to be lock-in. The vendor will make decisions on direction based upon their business needs. If their needs and your needs align, very good. If they do not align, you could find yourself with some difficult and costly decisions.
The choices and decisions are not easy ones to make. But every corporation should be aware of the software market and the impact open-source offerings are starting to have.
Sunday, August 21, 2005
Unlocking the enterprise for open source | CNET News.com
Unlocking the enterprise for open source | CNET News.com
Good article from CNET on open-source software and its adoption into the corporate world. I know most companies are feeling pressure to reduce cost at every turn. Most companies are trying many different ways to do this: outsourcing, reduced benefits, pay cuts, increased automation, longer hours with fewer workers (thats your basic productivity number) and many other ways. Companies are also looking for ways to become more competitive.
Software and its associated cost remain a largely untapped source for cost reduction. And we know that software when used properly can give a corporation a competitive edge. I don't know that open-source software is a silver bullet (its not, really there is not such thing), but changing the way software is purchased, licensed and owned/maintained will eventually have a large impact on corporations and the bottom line. Some of which will be good and some maybe not so good (open-source licensing still has some kinks).
Good article from CNET on open-source software and its adoption into the corporate world. I know most companies are feeling pressure to reduce cost at every turn. Most companies are trying many different ways to do this: outsourcing, reduced benefits, pay cuts, increased automation, longer hours with fewer workers (thats your basic productivity number) and many other ways. Companies are also looking for ways to become more competitive.
Software and its associated cost remain a largely untapped source for cost reduction. And we know that software when used properly can give a corporation a competitive edge. I don't know that open-source software is a silver bullet (its not, really there is not such thing), but changing the way software is purchased, licensed and owned/maintained will eventually have a large impact on corporations and the bottom line. Some of which will be good and some maybe not so good (open-source licensing still has some kinks).
Saturday, August 20, 2005
ServiceMix - ServiceMix 1.0 Release
ServiceMix - ServiceMix 1.0 Release
Another open-source ESB enters the mix. These are becoming more numerous. None of these are of the quality or feature set of a webMethods or Tibco. But will they eventually put any pressure on the pure play vendors? Only time will tell but certainly something to watch.
Another open-source ESB enters the mix. These are becoming more numerous. None of these are of the quality or feature set of a webMethods or Tibco. But will they eventually put any pressure on the pure play vendors? Only time will tell but certainly something to watch.
Thursday, August 18, 2005
Zotob, PnP Worms Slam 13 DaimlerChrysler Plants - Yahoo! News
Zotob, PnP Worms Slam 13 DaimlerChrysler Plants - Yahoo! News
I've always wondered why Chrysler had more defects in their cars than anyone else. Using Windows as a critical part of the assembly line seems to explain a lot.
I've always wondered why Chrysler had more defects in their cars than anyone else. Using Windows as a critical part of the assembly line seems to explain a lot.
Monday, August 01, 2005
Developers and Infrastructure
How much do developers really need to know about infrastructure? I read an article recently about developers becoming further removed from the infrastructure. Which on the surface sounds pretty good. Tools make you more productive, auto generating this and that. But how does that play out in the integration landscape? The more abstracted the developer becomes from the underlying infrastructure, the less likely the developer is going to be able to deliver reliable integrations. So what does that really mean?
Integration reliability depends on the developer understanding the infrastructure. What happens when the network is down? What happens when a database connect fails? What happens if two targets are updated but the third one fails? How does the integration respond to the various runtime errors that can occur when traversing multiple distributed systems? Most of this stuff takes place asynchronously making the matter even more difficult. I plan sharing some my experiences with designing for these types of events in the integration layer. Some of the hard lessons learned.
Integration reliability depends on the developer understanding the infrastructure. What happens when the network is down? What happens when a database connect fails? What happens if two targets are updated but the third one fails? How does the integration respond to the various runtime errors that can occur when traversing multiple distributed systems? Most of this stuff takes place asynchronously making the matter even more difficult. I plan sharing some my experiences with designing for these types of events in the integration layer. Some of the hard lessons learned.
Subscribe to:
Posts (Atom)