Loading ...
Sorry, an error occurred while loading the content.

Re: Schulte on ESBs

Expand Messages
  • Dr. Awel Dico
    The originator of the ESB idea, i.e. Gartner, has answered the question ESB - Product or pattern? . It is now aggreed up on that it is useful to think of ESB
    Message 1 of 7 , Mar 31, 2005
    • 0 Attachment
      The originator of the ESB idea, i.e. Gartner, has answered the
      question "ESB - Product or pattern?". It is now aggreed up on that
      it is useful to think of ESB both ways. It is architectural pattern
      when you address SOA implementation - this allows you to implement
      your target architecture increamentally based on business need. For
      example, an organization may not need BPEL support initially and may
      plug-in this functionality to its SOA infrastructure when needed.
      Regardless, the target architecture may still capture all that ESB
      (as a pattern) has to offer.
      On the other hand, it is also useful to think interms of product -
      when physical architecture is considered. An organization may deploy
      ESB platform with minimal functionalities and extend (add) more
      functionality by extending existing ESB platform or deploying a new
      ESB platform.

      There are many ESB related questions. For example, on one of
      conferences I attened (facilitated by gartner), I asked the
      relationship between ESB, Service Registry and Service management.
      The answer rests on the implementation of WS-standards such as wS-
      Policy, UDDI, WSDM and WS-security ...

      Regards,
      Awel Dico
      http://soacorner.blogspot.com


      --- In service-orientated-architecture@yahoogroups.com, Amit Gupta
      <am_gupta@y...> wrote:
      >
      > > "An ESB is something you buy like a DBMS," Schulte
      > > said.
      > >
      > +1. I agree as well. ESB is not just a architecture ,
      > but a platform which can simplify distributed event
      > driven process development with "minimum" (or no)
      > coding.
      >
      > > Big Blue has been showing how its existing products
      > > can be used as an ESB simply by writing some custom
      > > code and employing certain design principles
      > >
      > Exactly. A key consitituent for delivering value from
      > an ESB deployment is it's inherent support for BCA
      > (Business Component Architecture) - which is what
      > enables replacing "custom code" by "reusable business
      > components".
      >
      > Thanks,
      > Amit Gupta
      > amitg@f...
      > www.fiorano.com
      >
      > Dave Wrote:-
      >
      > > I think the most important part of this article is
      > > where Roy weighs in on the ESB "pattern vs. product"
      > > debate -
      > >
      > > ESB isn't a design pattern, but IBM has been
      > > discussing it that way,
      > > Schulte said. Big Blue has been showing how its
      > > existing products can be
      > > used as an ESB simply by writing some custom code
      > > and employing certain
      > > design principles.
      > >
      > > "An ESB is something you buy like a DBMS," Schulte
      > > said. "A DBMS is not
      > > a design pattern, it's a piece of software. Just as
      > > you can either write
      > > your own DBMS or buy one, so too can you buy an ESB
      > > or write your own."
      > >
      > > I agree with Roy's view on this :-)
      > >
      > > Dave
      > >
      > > ________________________________
      > >
      > > From: Gervas Douglas
      > > [mailto:gervasdouglas@y...]
      > > Sent: Thursday, March 24, 2005 1:25 PM
      > > To: service-orientated-architecture@yahoogroups.com
      > > Subject: [service-orientated-architecture] Schulte
      > > on ESBs
      > >
      > >
      > >
      > >
      > >
      > > <<In a report published last November, Gartner
      > > predicted that more
      > > than half of all large enterprises will have an ESB
      > > running by
      > > year-end 2006.
      > >
      > > Sonic was the first vendor to ship an ESB product in
      > > 2002. Built on
      > > top of its Java Message Service (JMS) product, it
      > > adds capabilities
      > > for Web services, event management and XML
      > > databases.
      > >
      > > Iona's Artix 3.0, on the other hand, has a
      > > transport-independent
      > > architecture that allows customers to plug-in any
      > > kind of messaging
      > > backbone, according to Schulte.
      > >
      > > "Whereas Sonic is wedded to its own messaging
      > > system, Artix is more of
      > > a layered product that can plug in different
      > > messaging systems and
      > > operate exactly the same way," Schulte said.
      > >
      > > But Sonic's JMS-based messaging system doesn't make
      > > it any less
      > > interoperable than Artix, according to Schulte.
      > >
      > > "You can still interoperate with Sonic using
      > > gateways to integrate
      > > with products like IBM MQSeries," he said. "The only
      > > difference is,
      > > you can't pull out their entire messaging layer
      > > whereas you can with
      > > Iona."
      > >
      > > ISB, USB, ESB ...
      > >
      > > All the confusion surrounding ESBs is partly the
      > > fault of vendors,
      > > Schulte said.
      > >
      > > "They used it as a [marketing] label on top of
      > > products that were
      > > fairly different from one another.">>
      > >
      > > You can find this at:
      > >
      > >
      >
      http://searchwebservices.techtarget.com/originalContent/0,289142,sid2
      6_g
      > > ci1071210,00.html?track=NL-110&ad=507789HOUSE
      > >
      > > Gervas
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > > Yahoo! Groups Sponsor
      > >
      > > ADVERTISEMENT
      > > click here
      > >
      >
      <http://us.ard.yahoo.com/SIG=129q3t3ao/M=298184.6191685.7192823.30011
      76/
      > >
      >
      D=groups/S=1705007181:HM/EXP=1111775176/A=2593423/R=0/SIG=11el9gslf/*
      htt
      > > p:/www.netflix.com/Default?mqso=60190075>
      > >
      > >
      > >
      > <http://us.adserver.yahoo.com/l?
      M=298184.6191685.7192823.3001176/D=group
      > > s/S=:HM/A=2593423/rand=305941692>
      > >
      > >
      > >
      > > ________________________________
      > >
      > > 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:
      > >
      > >
      > service-orientated-architecture-unsubscribe@yahoogroups.com
      > >
      > <mailto:service-orientated-architecture-
      unsubscribe@yahoogroups.com?subj
      > > ect=Unsubscribe>
      > >
      > > * Your use of Yahoo! Groups is subject to the Yahoo!
      > > Terms of
      > > Service <http://docs.yahoo.com/info/terms/> .
      > >
      > >
      >
      >
      >
      > __________________________________
      > Do you Yahoo!?
      > Yahoo! Small Business - Try our new resources site!
      > http://smallbusiness.yahoo.com/resources/
    • Amit Gupta
      ... I beg to differ. Scaling an implementation which is based on ESB pattern but not on ESB Product is definitely going to be a nightmare, as things get
      Message 2 of 7 , Apr 1, 2005
      • 0 Attachment
        > Regardless, the target architecture may still
        > capture all that ESB (as a pattern) has to offer.
        >
        I beg to differ. Scaling an implementation which is
        based on "ESB pattern" but not on "ESB Product" is
        definitely going to be a nightmare, as things get more
        and more complex in a deployment.

        It's almost exactly like implementing an application
        based on relational schema principals using a DB which
        does not support RDBMS..

        Thanks,
        Amit Gupta


        --- "Dr. Awel Dico" <aweldico@...> wrote:

        >
        >
        > The originator of the ESB idea, i.e. Gartner, has
        > answered the
        > question "ESB - Product or pattern?". It is now
        > aggreed up on that
        > it is useful to think of ESB both ways. It is
        > architectural pattern
        > when you address SOA implementation - this allows
        > you to implement
        > your target architecture increamentally based on
        > business need. For
        > example, an organization may not need BPEL support
        > initially and may
        > plug-in this functionality to its SOA infrastructure
        > when needed.
        > Regardless, the target architecture may still
        > capture all that ESB
        > (as a pattern) has to offer.
        > On the other hand, it is also useful to think
        > interms of product -
        > when physical architecture is considered. An
        > organization may deploy
        > ESB platform with minimal functionalities and extend
        > (add) more
        > functionality by extending existing ESB platform or
        > deploying a new
        > ESB platform.
        >
        > There are many ESB related questions. For example,
        > on one of
        > conferences I attened (facilitated by gartner), I
        > asked the
        > relationship between ESB, Service Registry and
        > Service management.
        > The answer rests on the implementation of
        > WS-standards such as wS-
        > Policy, UDDI, WSDM and WS-security ...
        >
        > Regards,
        > Awel Dico
        > http://soacorner.blogspot.com
        >
        >
        > --- In
        > service-orientated-architecture@yahoogroups.com,
        > Amit Gupta
        > <am_gupta@y...> wrote:
        > >
        > > > "An ESB is something you buy like a DBMS,"
        > Schulte
        > > > said.
        > > >
        > > +1. I agree as well. ESB is not just a
        > architecture ,
        > > but a platform which can simplify distributed
        > event
        > > driven process development with "minimum" (or no)
        > > coding.
        > >
        > > > Big Blue has been showing how its existing
        > products
        > > > can be used as an ESB simply by writing some
        > custom
        > > > code and employing certain design principles
        > > >
        > > Exactly. A key consitituent for delivering value
        > from
        > > an ESB deployment is it's inherent support for BCA
        > > (Business Component Architecture) - which is what
        > > enables replacing "custom code" by "reusable
        > business
        > > components".
        > >
        > > Thanks,
        > > Amit Gupta
        > > amitg@f...
        > > www.fiorano.com
        > >
        > > Dave Wrote:-
        > >
        > > > I think the most important part of this article
        > is
        > > > where Roy weighs in on the ESB "pattern vs.
        > product"
        > > > debate -
        > > >
        > > > ESB isn't a design pattern, but IBM has been
        > > > discussing it that way,
        > > > Schulte said. Big Blue has been showing how its
        > > > existing products can be
        > > > used as an ESB simply by writing some custom
        > code
        > > > and employing certain
        > > > design principles.
        > > >
        > > > "An ESB is something you buy like a DBMS,"
        > Schulte
        > > > said. "A DBMS is not
        > > > a design pattern, it's a piece of software. Just
        > as
        > > > you can either write
        > > > your own DBMS or buy one, so too can you buy an
        > ESB
        > > > or write your own."
        > > >
        > > > I agree with Roy's view on this :-)
        > > >
        > > > Dave
        > > >
        > > > ________________________________
        > > >
        > > > From: Gervas Douglas
        > > > [mailto:gervasdouglas@y...]
        > > > Sent: Thursday, March 24, 2005 1:25 PM
        > > > To:
        > service-orientated-architecture@yahoogroups.com
        > > > Subject: [service-orientated-architecture]
        > Schulte
        > > > on ESBs
        > > >
        > > >
        > > >
        > > >
        > > >
        > > > <<In a report published last November, Gartner
        > > > predicted that more
        > > > than half of all large enterprises will have an
        > ESB
        > > > running by
        > > > year-end 2006.
        > > >
        > > > Sonic was the first vendor to ship an ESB
        > product in
        > > > 2002. Built on
        > > > top of its Java Message Service (JMS) product,
        > it
        > > > adds capabilities
        > > > for Web services, event management and XML
        > > > databases.
        > > >
        > > > Iona's Artix 3.0, on the other hand, has a
        > > > transport-independent
        > > > architecture that allows customers to plug-in
        > any
        > > > kind of messaging
        > > > backbone, according to Schulte.
        > > >
        > > > "Whereas Sonic is wedded to its own messaging
        > > > system, Artix is more of
        > > > a layered product that can plug in different
        > > > messaging systems and
        > > > operate exactly the same way," Schulte said.
        > > >
        > > > But Sonic's JMS-based messaging system doesn't
        > make
        > > > it any less
        > > > interoperable than Artix, according to Schulte.
        > > >
        > > > "You can still interoperate with Sonic using
        > > > gateways to integrate
        > > > with products like IBM MQSeries," he said. "The
        > only
        > > > difference is,
        > > > you can't pull out their entire messaging layer
        > > > whereas you can with
        > > > Iona."
        > > >
        > > > ISB, USB, ESB ...
        > > >
        > > > All the confusion surrounding ESBs is partly the
        > > > fault of vendors,
        > > > Schulte said.
        > > >
        > > > "They used it as a [marketing] label on top of
        > > > products that were
        > > > fairly different from one another.">>
        > > >
        > > > You can find this at:
        > > >
        > > >
        > >
        >
        http://searchwebservices.techtarget.com/originalContent/0,289142,sid2
        > 6_g
        > > > ci1071210,00.html?track=NL-110&ad=507789HOUSE
        > > >
        > > > Gervas
        > > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > > > Yahoo! Groups Sponsor
        > > >
        > > > ADVERTISEMENT
        > > > click here
        >
        === message truncated ===


        __________________________________________________
        Do You Yahoo!?
        Tired of spam? Yahoo! Mail has the best spam protection around
        http://mail.yahoo.com
      • Dr. Awel Dico
        May be I wasn t clear in my wordings. I meant ESB can be viewed as a pattern in target architecture from enterprise architecture perspective - the vision, if
        Message 3 of 7 , Apr 1, 2005
        • 0 Attachment
          May be I wasn't clear in my wordings. I meant ESB can be viewed as a
          pattern in target architecture from enterprise architecture
          perspective - the vision, if that make sense. Then, the actual
          implementation of the vision can be done incrementally by evaluating
          and deploying a suitable ESB product. It is rather a nighmare to
          start implementation without having an enterprise target
          architecture.

          Regards,
          Awel Dico

          --- In service-orientated-architecture@yahoogroups.com, Amit Gupta
          <am_gupta@y...> wrote:
          >
          > > Regardless, the target architecture may still
          > > capture all that ESB (as a pattern) has to offer.
          > >
          > I beg to differ. Scaling an implementation which is
          > based on "ESB pattern" but not on "ESB Product" is
          > definitely going to be a nightmare, as things get more
          > and more complex in a deployment.
          >
          > It's almost exactly like implementing an application
          > based on relational schema principals using a DB which
          > does not support RDBMS..
          >
          > Thanks,
          > Amit Gupta
          >
          >
          > --- "Dr. Awel Dico" <aweldico@h...> wrote:
          >
          > >
          > >
          > > The originator of the ESB idea, i.e. Gartner, has
          > > answered the
          > > question "ESB - Product or pattern?". It is now
          > > aggreed up on that
          > > it is useful to think of ESB both ways. It is
          > > architectural pattern
          > > when you address SOA implementation - this allows
          > > you to implement
          > > your target architecture increamentally based on
          > > business need. For
          > > example, an organization may not need BPEL support
          > > initially and may
          > > plug-in this functionality to its SOA infrastructure
          > > when needed.
          > > Regardless, the target architecture may still
          > > capture all that ESB
          > > (as a pattern) has to offer.
          > > On the other hand, it is also useful to think
          > > interms of product -
          > > when physical architecture is considered. An
          > > organization may deploy
          > > ESB platform with minimal functionalities and extend
          > > (add) more
          > > functionality by extending existing ESB platform or
          > > deploying a new
          > > ESB platform.
          > >
          > > There are many ESB related questions. For example,
          > > on one of
          > > conferences I attened (facilitated by gartner), I
          > > asked the
          > > relationship between ESB, Service Registry and
          > > Service management.
          > > The answer rests on the implementation of
          > > WS-standards such as wS-
          > > Policy, UDDI, WSDM and WS-security ...
          > >
          > > Regards,
          > > Awel Dico
          > > http://soacorner.blogspot.com
          > >
          > >
          > > --- In
          > > service-orientated-architecture@yahoogroups.com,
          > > Amit Gupta
          > > <am_gupta@y...> wrote:
          > > >
          > > > > "An ESB is something you buy like a DBMS,"
          > > Schulte
          > > > > said.
          > > > >
          > > > +1. I agree as well. ESB is not just a
          > > architecture ,
          > > > but a platform which can simplify distributed
          > > event
          > > > driven process development with "minimum" (or no)
          > > > coding.
          > > >
          > > > > Big Blue has been showing how its existing
          > > products
          > > > > can be used as an ESB simply by writing some
          > > custom
          > > > > code and employing certain design principles
          > > > >
          > > > Exactly. A key consitituent for delivering value
          > > from
          > > > an ESB deployment is it's inherent support for BCA
          > > > (Business Component Architecture) - which is what
          > > > enables replacing "custom code" by "reusable
          > > business
          > > > components".
          > > >
          > > > Thanks,
          > > > Amit Gupta
          > > > amitg@f...
          > > > www.fiorano.com
          > > >
          > > > Dave Wrote:-
          > > >
          > > > > I think the most important part of this article
          > > is
          > > > > where Roy weighs in on the ESB "pattern vs.
          > > product"
          > > > > debate -
          > > > >
          > > > > ESB isn't a design pattern, but IBM has been
          > > > > discussing it that way,
          > > > > Schulte said. Big Blue has been showing how its
          > > > > existing products can be
          > > > > used as an ESB simply by writing some custom
          > > code
          > > > > and employing certain
          > > > > design principles.
          > > > >
          > > > > "An ESB is something you buy like a DBMS,"
          > > Schulte
          > > > > said. "A DBMS is not
          > > > > a design pattern, it's a piece of software. Just
          > > as
          > > > > you can either write
          > > > > your own DBMS or buy one, so too can you buy an
          > > ESB
          > > > > or write your own."
          > > > >
          > > > > I agree with Roy's view on this :-)
          > > > >
          > > > > Dave
          > > > >
          > > > > ________________________________
          > > > >
          > > > > From: Gervas Douglas
          > > > > [mailto:gervasdouglas@y...]
          > > > > Sent: Thursday, March 24, 2005 1:25 PM
          > > > > To:
          > > service-orientated-architecture@yahoogroups.com
          > > > > Subject: [service-orientated-architecture]
          > > Schulte
          > > > > on ESBs
          > > > >
          > > > >
          > > > >
          > > > >
          > > > >
          > > > > <<In a report published last November, Gartner
          > > > > predicted that more
          > > > > than half of all large enterprises will have an
          > > ESB
          > > > > running by
          > > > > year-end 2006.
          > > > >
          > > > > Sonic was the first vendor to ship an ESB
          > > product in
          > > > > 2002. Built on
          > > > > top of its Java Message Service (JMS) product,
          > > it
          > > > > adds capabilities
          > > > > for Web services, event management and XML
          > > > > databases.
          > > > >
          > > > > Iona's Artix 3.0, on the other hand, has a
          > > > > transport-independent
          > > > > architecture that allows customers to plug-in
          > > any
          > > > > kind of messaging
          > > > > backbone, according to Schulte.
          > > > >
          > > > > "Whereas Sonic is wedded to its own messaging
          > > > > system, Artix is more of
          > > > > a layered product that can plug in different
          > > > > messaging systems and
          > > > > operate exactly the same way," Schulte said.
          > > > >
          > > > > But Sonic's JMS-based messaging system doesn't
          > > make
          > > > > it any less
          > > > > interoperable than Artix, according to Schulte.
          > > > >
          > > > > "You can still interoperate with Sonic using
          > > > > gateways to integrate
          > > > > with products like IBM MQSeries," he said. "The
          > > only
          > > > > difference is,
          > > > > you can't pull out their entire messaging layer
          > > > > whereas you can with
          > > > > Iona."
          > > > >
          > > > > ISB, USB, ESB ...
          > > > >
          > > > > All the confusion surrounding ESBs is partly the
          > > > > fault of vendors,
          > > > > Schulte said.
          > > > >
          > > > > "They used it as a [marketing] label on top of
          > > > > products that were
          > > > > fairly different from one another.">>
          > > > >
          > > > > You can find this at:
          > > > >
          > > > >
          > > >
          > >
          >
          http://searchwebservices.techtarget.com/originalContent/0,289142,sid2
          > > 6_g
          > > > > ci1071210,00.html?track=NL-110&ad=507789HOUSE
          > > > >
          > > > > Gervas
          > > > >
          > > > >
          > > > >
          > > > >
          > > > >
          > > > >
          > > > >
          > > > >
          > > > >
          > > > >
          > > > > Yahoo! Groups Sponsor
          > > > >
          > > > > ADVERTISEMENT
          > > > > click here
          > >
          > === message truncated ===
          >
          >
          > __________________________________________________
          > Do You Yahoo!?
          > Tired of spam? Yahoo! Mail has the best spam protection around
          > http://mail.yahoo.com
        • Amit Gupta
          Thanks for clarifications. This looks well in line with my views as well. Thanks, Amit Gupta amitg@fiorano.com ... === message truncated ===
          Message 4 of 7 , Apr 1, 2005
          • 0 Attachment
            Thanks for clarifications. This looks well in line
            with my views as well.

            Thanks,
            Amit Gupta
            amitg@...

            --- "Dr. Awel Dico" <aweldico@...> wrote:

            >
            >
            > May be I wasn't clear in my wordings. I meant ESB
            > can be viewed as a
            > pattern in target architecture from enterprise
            > architecture
            > perspective - the vision, if that make sense. Then,
            > the actual
            > implementation of the vision can be done
            > incrementally by evaluating
            > and deploying a suitable ESB product. It is rather a
            > nighmare to
            > start implementation without having an enterprise
            > target
            > architecture.
            >
            > Regards,
            > Awel Dico
            >
            > --- In
            > service-orientated-architecture@yahoogroups.com,
            > Amit Gupta
            > <am_gupta@y...> wrote:
            > >
            > > > Regardless, the target architecture may still
            > > > capture all that ESB (as a pattern) has to
            > offer.
            > > >
            > > I beg to differ. Scaling an implementation which
            > is
            > > based on "ESB pattern" but not on "ESB Product" is
            > > definitely going to be a nightmare, as things get
            > more
            > > and more complex in a deployment.
            > >
            > > It's almost exactly like implementing an
            > application
            > > based on relational schema principals using a DB
            > which
            > > does not support RDBMS..
            > >
            > > Thanks,
            > > Amit Gupta
            > >
            > >
            > > --- "Dr. Awel Dico" <aweldico@h...> wrote:
            > >
            > > >
            > > >
            > > > The originator of the ESB idea, i.e. Gartner,
            > has
            > > > answered the
            > > > question "ESB - Product or pattern?". It is now
            > > > aggreed up on that
            > > > it is useful to think of ESB both ways. It is
            > > > architectural pattern
            > > > when you address SOA implementation - this
            > allows
            > > > you to implement
            > > > your target architecture increamentally based on
            > > > business need. For
            > > > example, an organization may not need BPEL
            > support
            > > > initially and may
            > > > plug-in this functionality to its SOA
            > infrastructure
            > > > when needed.
            > > > Regardless, the target architecture may still
            > > > capture all that ESB
            > > > (as a pattern) has to offer.
            > > > On the other hand, it is also useful to think
            > > > interms of product -
            > > > when physical architecture is considered. An
            > > > organization may deploy
            > > > ESB platform with minimal functionalities and
            > extend
            > > > (add) more
            > > > functionality by extending existing ESB platform
            > or
            > > > deploying a new
            > > > ESB platform.
            > > >
            > > > There are many ESB related questions. For
            > example,
            > > > on one of
            > > > conferences I attened (facilitated by gartner),
            > I
            > > > asked the
            > > > relationship between ESB, Service Registry and
            > > > Service management.
            > > > The answer rests on the implementation of
            > > > WS-standards such as wS-
            > > > Policy, UDDI, WSDM and WS-security ...
            > > >
            > > > Regards,
            > > > Awel Dico
            > > > http://soacorner.blogspot.com
            > > >
            > > >
            > > > --- In
            > > > service-orientated-architecture@yahoogroups.com,
            > > > Amit Gupta
            > > > <am_gupta@y...> wrote:
            > > > >
            > > > > > "An ESB is something you buy like a DBMS,"
            > > > Schulte
            > > > > > said.
            > > > > >
            > > > > +1. I agree as well. ESB is not just a
            > > > architecture ,
            > > > > but a platform which can simplify distributed
            > > > event
            > > > > driven process development with "minimum" (or
            > no)
            > > > > coding.
            > > > >
            > > > > > Big Blue has been showing how its existing
            > > > products
            > > > > > can be used as an ESB simply by writing some
            > > > custom
            > > > > > code and employing certain design principles
            > > > > >
            > > > > Exactly. A key consitituent for delivering
            > value
            > > > from
            > > > > an ESB deployment is it's inherent support for
            > BCA
            > > > > (Business Component Architecture) - which is
            > what
            > > > > enables replacing "custom code" by "reusable
            > > > business
            > > > > components".
            > > > >
            > > > > Thanks,
            > > > > Amit Gupta
            > > > > amitg@f...
            > > > > www.fiorano.com
            > > > >
            > > > > Dave Wrote:-
            > > > >
            > > > > > I think the most important part of this
            > article
            > > > is
            > > > > > where Roy weighs in on the ESB "pattern vs.
            > > > product"
            > > > > > debate -
            > > > > >
            > > > > > ESB isn't a design pattern, but IBM has been
            > > > > > discussing it that way,
            > > > > > Schulte said. Big Blue has been showing how
            > its
            > > > > > existing products can be
            > > > > > used as an ESB simply by writing some custom
            > > > code
            > > > > > and employing certain
            > > > > > design principles.
            > > > > >
            > > > > > "An ESB is something you buy like a DBMS,"
            > > > Schulte
            > > > > > said. "A DBMS is not
            > > > > > a design pattern, it's a piece of software.
            > Just
            > > > as
            > > > > > you can either write
            > > > > > your own DBMS or buy one, so too can you buy
            > an
            > > > ESB
            > > > > > or write your own."
            > > > > >
            > > > > > I agree with Roy's view on this :-)
            > > > > >
            > > > > > Dave
            > > > > >
            > > > > > ________________________________
            > > > > >
            > > > > > From: Gervas Douglas
            > > > > > [mailto:gervasdouglas@y...]
            > > > > > Sent: Thursday, March 24, 2005 1:25 PM
            > > > > > To:
            > > > service-orientated-architecture@yahoogroups.com
            > > > > > Subject: [service-orientated-architecture]
            > > > Schulte
            > > > > > on ESBs
            > > > > >
            > > > > >
            > > > > >
            > > > > >
            > > > > >
            > > > > > <<In a report published last November,
            > Gartner
            > > > > > predicted that more
            > > > > > than half of all large enterprises will have
            > an
            > > > ESB
            > > > > > running by
            > > > > > year-end 2006.
            > > > > >
            > > > > > Sonic was the first vendor to ship an ESB
            > > > product in
            > > > > > 2002. Built on
            > > > > > top of its Java Message Service (JMS)
            > product,
            >
            === message truncated ===




            __________________________________
            Yahoo! Messenger
            Show us what our next emoticon should look like. Join the fun.
            http://www.advision.webevents.yahoo.com/emoticontest
          Your message has been successfully submitted and would be delivered to recipients shortly.