The confrence is in grapevine TX, right near Dallas.
As my wife is joining me on this trip we decided to fly into Austin and drive to Dallas. I lived in Austin for a whe, andwanted to sow her some of my old haunts.
We were unable to carve out much time for Austin, and rain dampened some of the experience, but I was able to show my wife enough she'll be eager to go back.
If you get to Austin:
Rudy's BBQ
Oasis on lake travis
6th street at night
4th street too
hills on north Austin (arboretum area).
I also will be looking for a chance to get back to San Antonio.
The drive from Austin to Dallas was smooth, although there was an accident requiring 2 medivac helicopters, which had I-35 shut dow both ways for a short strech.
The confrence is at a very nice, and huge resort and convention center; the Gaylord Texan.
Monday, September 12, 2005
Gartner application development summit
This week I'm attending the Gartner Application Development Summit, and Enterprise Architecture Summit.
In 2003 I attended the Gartner Application Integration and Web Services summit.
Over the next few days I'll be posting both current messages from my attendance, as well as changes from what I remember. I'll also give some personal experience and perspective.
In 2003 I attended the Gartner Application Integration and Web Services summit.
Over the next few days I'll be posting both current messages from my attendance, as well as changes from what I remember. I'll also give some personal experience and perspective.
Saturday, August 27, 2005
Monday, August 22, 2005
The Bus Stops here
Phil Wainewright has some excellent points here. The premise of an ESB is the real question isn't it?
If ESB is a package, and that package is designed to enable SOA and merely to be more standards compliant and less costly than traditional EAI then yes the emergence of WS-Relability and WS-ReliableMessaging will reduce the need for a packaged ESB.
However if you consider the ESB to be a SOA pattern, and ESB vendors offering an implementaiton of that pattern, then the ESB is just fullfilling its own promise. The promise behind a standards based pattern is that certain implementation aspects will be driven to be commodity, and vendors will need to innovate to differentiate their products as they recognise each layer of the ESB should be swapable for the best of breed providers solution.
Further, custom adapters will not go away anytime soon, there are a multitude of proprietary legacy systems that adapters are the only connectivity and EAI vendors are the niche players.
Additionally if you consider ESB as a pattern, then it is very acceptable to have a few implementations of that pattern and federate accross them (its part of the pattern). The standards provide the glue to integrate and federate an set of ESB's.
Continued standards development is key for driving the ever increasing value of SOA-enabled enterprise, and those enterprises at the bleeding edge are realizing the ROI to justify some level of errosion of competitive advantage in trade off for standards that enable further competitive advantage development.
So its not the end of the road for the service bus, the bus just got a new paint job.
If ESB is a package, and that package is designed to enable SOA and merely to be more standards compliant and less costly than traditional EAI then yes the emergence of WS-Relability and WS-ReliableMessaging will reduce the need for a packaged ESB.
However if you consider the ESB to be a SOA pattern, and ESB vendors offering an implementaiton of that pattern, then the ESB is just fullfilling its own promise. The promise behind a standards based pattern is that certain implementation aspects will be driven to be commodity, and vendors will need to innovate to differentiate their products as they recognise each layer of the ESB should be swapable for the best of breed providers solution.
Further, custom adapters will not go away anytime soon, there are a multitude of proprietary legacy systems that adapters are the only connectivity and EAI vendors are the niche players.
Additionally if you consider ESB as a pattern, then it is very acceptable to have a few implementations of that pattern and federate accross them (its part of the pattern). The standards provide the glue to integrate and federate an set of ESB's.
Continued standards development is key for driving the ever increasing value of SOA-enabled enterprise, and those enterprises at the bleeding edge are realizing the ROI to justify some level of errosion of competitive advantage in trade off for standards that enable further competitive advantage development.
So its not the end of the road for the service bus, the bus just got a new paint job.
Microsoft Position on ESB
Another point from the aforementioned paper is that ESB == EAI.
To some degree this is true, but ESB is actually the evolution of EAI concepts.
To say you are using EAI technologies does not imply SOA, nor does it imply standards based connectivity. It does imply advanced messaging capabilities, and brokered communications.
An ESB implies security, standards based connectivity, as well as service registry and service mapping. These are what differentiates an ESB from plain old EAI.
The current SOA and ESB movements don't claim to do anything new, but rather evolve best of breed architectures that have been used in the past, while reducing barriers to entry and common failure factors.
To some degree this is true, but ESB is actually the evolution of EAI concepts.
To say you are using EAI technologies does not imply SOA, nor does it imply standards based connectivity. It does imply advanced messaging capabilities, and brokered communications.
An ESB implies security, standards based connectivity, as well as service registry and service mapping. These are what differentiates an ESB from plain old EAI.
The current SOA and ESB movements don't claim to do anything new, but rather evolve best of breed architectures that have been used in the past, while reducing barriers to entry and common failure factors.
Sunday, August 21, 2005
Microsoft postion on ESB
I reviewed the document posted by Scott Woodgate on Microsoft's position on the enterprise service bus.
To distill the document:
I see the ESB as offering the following features:
To distill the document:
- The author believes ESB is a transitionary stage not a product.
- The author believes the functionality of an ESB is offered by Microsoft in superset of functionality.
I see the ESB as offering the following features:
- Standards based broker
- Publish and Subscribe Queues (including publish once)
- Gauranteed Delivery
- Data Transformation
- Access Control
- Service Mappings
- Service Registry
- Data Caching
- BPM hooks
- Intelligent Routing (Workflow)
- Audting/Error logging
- Monitoring
I have a slide on this but am not sure I'm permitted to publish it online. The Enterprise Service Bus is an architectural pattern, as well as a product class.
From a functionality perspective I agree that Microsoft has the technology to deliver this list, Windows Communication Framework takes this even further.
I have to disagree with the authors point of view that ESB's are a transitionary stage and shouldn't be a product.
The ESB, even when federated with other service buses, provides all the value of a standard integration broker with the added advantage of standards support, but it goes further to provide abstracted functionality thats not system dependent including workflow capabilities, while centralizing service definition and auditing and logging. This is incredibly powerfull in a enterprise environment as it provides distribution and loose coupling for speed and agility while still centralizing for code reuse, standardization, monitoring, and most importantly, governance.
Lastly the ESB provides an opportunity to define a standard colloquial business languange, which can act as an intermediary translator between system specific terminology. This purposes to save tremendous translation work as new and existing systems only ever must be integrated to one "language" rather than the language of each system it must be integrated too.
Because of this abstraction of functionaliy, and centralization of services and governance enterprises can get the optimal ROI for their SOA efforts.
Product stacks fitted into the ESB umbrella are key players in to realize value on this front, as they can provide comprehensive offerings and can extend them to add further value. If each component operates and connects based on standards the component becomes a commodity and the vendor will need to embrace this and look for ways to differentiate by providing further value. Predictive analysis, out-of-the box services, and service throughput analysis are some areas for such value add.
Product stacks also can simplify setup, installation, and maintance to assist in reducing TCO of SOA.
While Microsoft has the peices to create a strong ESB stack it disappoints meet to see this paper miss the mark, rather than suggest Microsoft ESB construction.
Feedburner
I'm intrested in rss monitoring, and as such I'm giving the free services of feedburner a try. Notice the little "0 readers" icon on the web-views right menu.
Feedburner replicates the xml feed, and tracks the hits to all that hit the replicated feed. So if your using the previous feed url (atom.xml) you won't have to change anything. Anyone bookmarking the feedburner url will show up in statists.
Feedburner replicates the xml feed, and tracks the hits to all that hit the replicated feed. So if your using the previous feed url (atom.xml) you won't have to change anything. Anyone bookmarking the feedburner url will show up in statists.
Subscribe to:
Posts (Atom)