Todd, Agree with what you've stated. I'm just calling "what's in the middle" an ESB. Someone might call it something else.
And as Eric stated out, the question is whether there should be a bridge functionality between HTTP and existing environment in "what's in the middle". H.Ozawa Todd Biske wrote: > As we all know, there's no right answer to this equation. When Web > Services were first being touted, one would have thought that there > would be no need for anything "in the middle" in the future. The > truth is, there will always be a need for something in the middle. I > called it the Service/Event Delivery Network, and not all of the > capabilities are associated with protocol or some other mediation. > The important thing is to focus on the capabilities, and make the > decision that's best for your organization, whether it's WCF, ESB, > SCA, XML Appliances, JINI, etc. They will all work. > > My opinion is that the most important thing to understand is what > things should be "in the middle" and what things shouldn't. My > definition of "in the middle" is loosely described as out of the > source code of the consumer or provider. In other words, > externalized in the form of policy-driven logic that can be > configured, rather than coded. You might be configuring the > underlying development framework, you might be configuring an ESB, an > XML appliance, whatever. If we really had a perfect world, the tools > used to set those policies and configure the run-time environment > would be independent of which product/technologies were chosen. > > Speaking of policy-driven infrastructure, any thoughts on the BEA > acquisition? I always thought Systinet and Flashline were more > competitors than collaborators, although I have zero experience with > either product in the recent past, so perhaps the competition was more > "in the future" than today. After all, Systinet definitely grew more > from the run-time world and Flashline grew from the development time > side. > > -tb > > On Aug 23, 2006, at 5:02 PM, Stefan Tilkov wrote: > >> On Aug 23, 2006, at 6:51 PM, Anne Thomas Manes wrote: >> >>> +1. >>> But many times you don't have the luxury of homogeneous systems. >>> >>> Anne >>> >> Anne, you are right, of course, but I wonder if even then an ESB is >> the right concept. >> >> For example, in a company there may be CICS/COBOL, CORBA/C++, EJB, >> and .NET services. In this example, I can either >> >> (1) select an ESB that supports all of these >> (2) for each technology, select some product that service-enables it >> >> Stefan >> >>> On 8/23/06, Stefan Tilkov < [EMAIL PROTECTED] >> <mailto:stefan.tilkov%40innoq.com>> wrote: >>> >>> On Aug 22, 2006, at 1:42 PM, Anne Thomas Manes wrote: >>> >>> > Some might argue that a uniform programming interface to multiple >>> > middlewares is a desirable thing. Why incur the extra cost of >>> > protocol switching in an intermediary if you can simply package >>> > your message in the correct protocol right from the start. The >>> > client is going to do marshalling/unmarshalling regardless, so >>> > there's no extra burden on the client. (It isn't performing >>> > protocol switching -- it simply calls the appropriate protocol plug- >>> > in/channel to marshal the request. A well-crafted framework should >>> > treat all protocols as equals.) >>> >>> I think it's also worth pointing out that this comes at a cost - >>> creating a common abstraction above multiple protocols is costly, >>> complicated, leaky, and might not work the way one wants to because >>> although a framework might *consider* protocols equal, they simply >>> *are* not. >>> >>> Instead of supporting multiple protocols and using a single framework >>> to support them all, I much prefer to standardize on a protocol and >>> support multiple frameworks. In other words: Standardize on plain >>> HTTP or WS-I BP instead of some ESB or CSIF. >>> >>> Stefan >>> -- >>> Stefan Tilkov, http://www.innoq. >> <http://www.innoq.com/blog/st/>com/blog/st/ >>> >>> >>> >>> >>> >> > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
