Todd, I agree with you on both points. To underscore the last one first, I believe open source will not only eventually overtake commercial products, but the community will also become a source of innovation.
On the initial point about developers, I believe you are referring to configurable solutions. I also think this is very important, and we are definitely working in this direction. That is one of the interesting aspects of SCA, by the way. Overall though - and although I'm not on the IT side right now, that is where I started my career - I would say that what we are heading for is a division of labor situation in which developers will be tasked primarily with creating services that are easy for others to configure into applications. I see both roles continuing but divided, whereas today developers tend to work in both areas, or applications are developed in a kind of turnkey fashion. Eric --- Todd Biske <[EMAIL PROTECTED]> wrote: > I actually don't think the issue is the > JMS-centricity of some > products as Eric implies. It definitely contributes > to the > controversy, but I wouldn't say it's the main issue. > As an end user > working primarily on the infrastructure side of > things, I've had to > give a lot of time and thought to this space. I've > actually brought > it down to one major point. Do you want the space > in the middle to > be the domain of developers or the domain of > operations? On the one > hand, we have flexibility. Flexibility will require > some more skill > in getting the product do what you want it to do. > This typically > will fall to the development staff. For example, an > application > server is a very flexible product. On the other end > of the spectrum > are the niche needs in the middle: routing, > security, etc. These are > configure-and-go black boxes that can be completely > handled by the > operations staff. > > For at least the near term, companies will exist > that have needs > across the whole spectrum. Only time will tell what > winds up > defining the product space that comprises the SOA > infrastructure. > Eventually, the common needs will come out, and the > product space > will converge. Personally, the thing that I find > the most > interesting going on in this space is the open > source efforts. The > reason for this is that you now have open source > products competing > against appliances (and closed source), rather than > against closed > source products. I'm not sure how it will turn out, > but it's fun to > watch. > > -tb > > On Mar 7, 2006, at 3:21 PM, Awel Dico wrote: > > > Hi Eric; > > > > It is a good observation as to how the vendors are > approaching the > > ESB product implementation. That diversity may be > positive for the > > users - choose what best fit to their situation. > The reality from > > your customers (users) perspective is different > though. Many > > enterprises do not just go and buy those "ESB > products". They look > > at the ESB capabilities as a pattern first - at > least from the point > > of view of the enterprise I work for. With clear > understanding of > > the capabilities, they map those capabilities with > the SOA > > infrastructure requirement. This is important > because you may not > > need ESB at all (XML appliances may do the job); > or it is something > > that you need right away, or it may be something > for the future. The > > enterprise architecture has to come up with the > SOA technology > > infrastructure reference architecture accordingly. > Based on the > > understanding of the capabilities required and > enterprise > > architectural guidelines, they start to evaluate > ESB products - may > > take them for a test drive (Proof-of-concept > type). The point I am > > trying to make here is that it is not an issue or > controversial from > > the users perspective. It may be an issue from > vendor's perspective. > > > > Regards, > > Dico > > > >> The result on the one hand is JMS centric while > on the > >> other ours is a multi-communications protocol, > multi > >> data format, brokerless, hubless distributed > >> architecture much better suited for SOA > >> infrastructure. > >> > >> Unfortunately it seems like most vendors are > adopting > >> the JMS centric approach, and that is what leads > to > >> the controversy. > > > > > > --- In > [email protected], > Eric > > Newcomer <[EMAIL PROTECTED]> wrote: > >> > >> A lot of posts to this group, and recent blogs by > Joe > >> McKendrick among others, have brought up the > debate > >> again about the Enterprise Service Bus. > >> > >> For the most recent, see: > >> > http://blogs.zdnet.com/service-oriented/index.php?p=560 > >> > >> Among the questions debated here is the lifetime > of > >> the ESB product category. Some suggest that it's > a > >> temporary product category, soon to be subsumed > by > >> something else. > >> > >> I'm not so sure. It takes a long time for a new > >> product category to get established. Just ask > our > >> friends at Sonic ;-). > >> > >> And with IBM, BEA, Oracle, Tibco, and others > recently > >> announcing they would ship an ESB the product > category > >> has definitely been validated and, I believe, > >> established. > >> > >> But what is an ESB? This question does indeed > >> continue to trouble the industry, since it still > seems > >> as if every vendor has a different definition. > >> > >> Several months ago I was invited to help deliver > a 3 > >> -hour tutorial on SOA and ESBs together with > David > >> Chappell of Sonic. He ended up injuring himself > in a > >> water skiing accident (which he blogged about) > shortly > >> before the tutorial date, so while the two of us > >> collaborated on the development of the > presentation a > >> colleague of Dave's ended up physically joining > me in > >> Washington for the event. > >> > >> The way we split things up was: > >> > >> -- I did about 45 minutes on generic SOA > >> -- Dave did about 45 minutes on generic ESB > >> -- Each of us did about 30 minutes on our > >> technologies, Artix and Sonic ESB, respectively > >> > >> (With breaks and Q&A that filled the time.) > >> > >> The interesting thing to me was how well the two > of us > >> could agree on the generic SOA and ESB > definitions. I > >> would say it was like 90-95%. Where we diverged > was > >> in our respective approaches to addressing the > >> requirements of SOA infrastructure, aka our ESB > >> products. > >> > >> I think up to this point Dave would agree with > >> everything I've said. Now I will give my view. > >> > >> The difference is that Sonic started with its > >> successful JMS product and added Web services > support > >> and other elements of integration software in > order to > >> create an ESB that meets SOA infrastructure > >> requirements. > >> > >> We started with our patented configurable > microkernel, > >> ART, and added a Web services "personality" aka > >> collection of plugins. > >> > >> The result on the one hand is JMS centric while > on the > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 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/
