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

RE: [service-orientated-architecture] Role of MOM in a Web Services based SOA

Expand Messages
  • Sarode, Prashant
    Todd, I have faced similar issues. Some services have long running transactions and consumers cannot wait. This seams to be MOM playing field. But very often
    Message 1 of 8 , Oct 31, 2005
    • 0 Attachment
      Role of MOM in a Web Services based SOA

      Todd,

      I have faced similar issues. Some services have long running transactions and consumers cannot wait. This seams to be MOM playing field. But very often than not, I have found that consumers prefer to send a synch-SOAP message as opposed to directly interacting with MOM providers (IBM-MQ, SeeBeyond or WLS JMS). In this case the Synch-SOAP call made to producer merely just to PUSH the message. Behind the producer lies a mechanism to safe store the message and then drop the message into the MOM. Once the message is into the service ---from their onwards everything is asynch.

       

      In the above scenarios we still have to deal with the “inherent unreliability” of HTTP. But so far I have not found that as big deal with the consumers. In fact, they (consumers) build some kind of notifications and re-try systems on their side if the HTTP service call fails. Also, Enterprise Management and Monitoring is anyway build to quickly detect (and fix) if service itself is down.  

       

      The other issue with the above approach is also –call back. Since the consumer “fires-&-forgets”, it has to come back later once again to check what happened to its request. Now this is somewhat painful (as this requires some kind of polling as opposed to getting back a call-back event from producer when it is done).

       

      The above 2 issues stay and make the Aysnch web services somewhat tricky. But with WS-Relaibility and WS-Addressing (to take care of call-backs)—I think these work-arounds will cease (though not day 1 but eventually). The problem is interoperability as opposed to availability of the technology---.Net to Java land is well covered but PowerBuilder, Excel, COBOL etc are yet to migrate from basic web services support (SOAP RPC-ENC ).

       

      I had hinted in my last post that Service does not have to be a “Web Service”. My definition is “service” is some piece of re-useable business logic (of significance) that needs to be exposed over multiple channels (web services, MQ, XML over HTPP) and perhaps it supports multiple modes of request-response model.

       

      By having a “Service” available over MOM and WS-channels extends the depth of SOA in organizations. This also means that your “service” reach & re-usability is beyond merely web service channel.

       

      Prashant Sarode

      Sr. Enterprise Architect

      Investors Bank & Trust Co.

      617 937 3154


      From: service-orientated-architecture@yahoogroups.com [mailto: service-orientated-architecture@yahoogroups.com ] On Behalf Of Biske, Todd
      Sent: Monday, October 31, 2005 12:54 PM
      To: service-orientated-architecture@yahoogroups.com
      Subject: [service-orientated-architecture] Role of MOM in a Web Services based SOA

       

      In the spirit of Gervas’ suggestion to turn the discussions on SOA infrastructure, I’m interested in what the group has to say about the role of MOM in a Web-Services based SOA. From an architectural perspective (i.e. technology indepedent), I don’t think there’s any argument that queuing systems are a key part of an SOA.  Once we actually try to implement the infrastructure required for an SOA, and build our services on top of it, we run into technology-specific issues.  One high up on my list is queuing systems.

      In my experience, there are two primary types of service invocations. The first is a push model.  The service consumer pushes the request to a service consumer, and blocks for a response.  Infrastructure is designed to handle some peak level, and blocking may occur for some amount of time if the number of concurrent requests exceeds the number of handlers available.   The second is a pull model.  In this case, the service consumer pushes the request to a queue, and service providers pull the requests off as they have handlers available.  A debate in this scenario is whether there ever can be a service response, as certainly some vendors have allowed the possibility with proprietary JMS endpoints in WSDL.  My preference is to treat all of these as fire and forget services.  Any message produced as a result should be viewed as a business event rather than as a service response.   My definition of an event versus a service message is that the service consumer has an expectation that some processing will occur with a service message, while an event has no implied processing. 

      There are several questions that arise around the pull model:

      • What’s the proper way of exposing these services?
      • Do we need a standard wire protocol for talking to a queue? 
      • When will queuing systems support SOAP natively?  Right now, we have mediation technology for SOAP/HTTP where everything is migrating toward policies based upon the SOAP envelope, not the HTTP envelope.  JMS providers focus on their proprietary JMS envelope (i.e. JMS properties) not on the SOAP envelope.
      • What if queuing providers exposed a Web Service for publishing to a queue?  What would this do to the functional model? 

       

      I’ve yet to see anyone really attack these problems head on.  While the ESB solutions built on top of a MOM do address this, they’re all proprietary solutions.  The only option that has some appeal is to utilize an HTTP to JMS/MQ/MSMQ bridge, provided that you accept my premise that all of these services are one-way invocations.  While this would address things from the consumer perspective (once WS-RM has broad support), it doesn’t quite fix things on the provider perspective.  We still don’t have a good answer for how this service should be exposed by the provider. 

      Thoughts?
      Todd Biske
      Software Infrastructure Engineering
      A.G. Edwards Technology Group, Inc.
      V:(314) 955-6254 F:(314) 955-4055 E:todd.biske@...



      -------------------------------------------------------------------------------------
      A.G. Edwards & Sons' outgoing and incoming e-mails are electronically
      archived and subject to review and/or disclosure to someone other
      than the recipient.

      -------------------------------------------------------------------------------------



      **************************************************************************
      This message and any attached documents contain information
      which may be confidential, subject to privilege or exempt from
      disclosure under applicable law. These materials are solely for
      the use of the intended recipient. If you are not the intended
      recipient of this transmission, you are hereby notified that any
      distribution, disclosure, printing, copying, storage, modification
      or the taking of any action in reliance upon this transmission is
      strictly prohibited. Delivery of this message to any person other
      than the intended recipient shall not compromise or waive
      such confidentiality, privilege or exemption from disclosure as
      to this communication.

      If you have received this communication in error, please notify
      the sender immediately and delete this message from your system.
      *****************************************************************************
    • Paul Fremantle
      Todd Firstly, good post. I agree this is a highly interesting and relevant discussion. I think the whole SOAP/JMS is basically a slight red herring, because it
      Message 2 of 8 , Oct 31, 2005
      • 0 Attachment
        Todd

        Firstly, good post. I agree this is a highly interesting and relevant discussion. I think the whole SOAP/JMS is basically a slight red herring, because it mixes up transport with semantics.T

         As you point out, there is a need for Web Services to support pull semantics as well as push semantics. For example, the submission by IBM of WS-Polling to the W3C ( http://www.w3.org/Submission/ws-polling/) creates an option to loosely couple services in time and directionality.

        The other relevant option is the Amazon Simple Queueing Service, http://www.amazon.com/gp/browse.html/104-4790757-2434363?_encoding=UTF8&node=13584001&no=13584171 , which provides  a WS mapping to a queueing paradigm.

        Both these options should be composable with reliability, and composable with SOAP transports, making a more flexible approach to choosing the right model (transport, QoS and semantic) compared to a JMS solution.

        Finally, I think that one thing that would be immensely useful would be a mapping from existing queueing models such as JMS into SOAP+RM+ a WSDL definition of queue transport. This would allow reliable interoperable bridging over SOAP/HTTP between JMS implementations which would be hugely valuable.

        Paul


        On 10/31/05, Biske, Todd <bisketa@...> wrote:

        In the spirit of Gervas' suggestion to turn the discussions on SOA infrastructure, I'm interested in what the group has to say about the role of MOM in a Web-Services based SOA. From an architectural perspective ( i.e. technology indepedent), I don't think there's any argument that queuing systems are a key part of an SOA.  Once we actually try to implement the infrastructure required for an SOA, and build our services on top of it, we run into technology-specific issues.  One high up on my list is queuing systems.

        In my experience, there are two primary types of service invocations. The first is a push model.  The service consumer pushes the request to a service consumer, and blocks for a response.  Infrastructure is designed to handle some peak level, and blocking may occur for some amount of time if the number of concurrent requests exceeds the number of handlers available.   The second is a pull model.  In this case, the service consumer pushes the request to a queue, and service providers pull the requests off as they have handlers available.  A debate in this scenario is whether there ever can be a service response, as certainly some vendors have allowed the possibility with proprietary JMS endpoints in WSDL.  My preference is to treat all of these as fire and forget services.  Any message produced as a result should be viewed as a business event rather than as a service response.   My definition of an event versus a service message is that the service consumer has an expectation that some processing will occur with a service message, while an event has no implied processing. 

        There are several questions that arise around the pull model:

        • What's the proper way of exposing these services?
        • Do we need a standard wire protocol for talking to a queue? 
        • When will queuing systems support SOAP natively?  Right now, we have mediation technology for SOAP/HTTP where everything is migrating toward policies based upon the SOAP envelope, not the HTTP envelope.  JMS providers focus on their proprietary JMS envelope ( i.e. JMS properties) not on the SOAP envelope.
        • What if queuing providers exposed a Web Service for publishing to a queue?  What would this do to the functional model? 

        I've yet to see anyone really attack these problems head on.  While the ESB solutions built on top of a MOM do address this, they're all proprietary solutions.  The only option that has some appeal is to utilize an HTTP to JMS/MQ/MSMQ bridge, provided that you accept my premise that all of these services are one-way invocations.  While this would address things from the consumer perspective (once WS-RM has broad support), it doesn't quite fix things on the provider perspective.  We still don't have a good answer for how this service should be exposed by the provider. 

        Thoughts?
        Todd Biske
        Software Infrastructure Engineering
        A.G. Edwards Technology Group, Inc.
        V:(314) 955-6254 F:(314) 955-4055 E:todd.biske@...



        -------------------------------------------------------------------------------------
        A.G. Edwards & Sons' outgoing and incoming e-mails are electronically
        archived and subject to review and/or disclosure to someone other
        than the recipient.

        -------------------------------------------------------------------------------------


        SPONSORED LINKS
        Service-oriented architecture Computer monitoring software Computer and internet software
        Free computer monitoring software


        YAHOO! GROUPS LINKS




      • Gregg Wonderly
        ... Web-Services based SOA. ... there s any ... to implement ... we run into ... This is a scarry statement. Are there really people going around talking
        Message 3 of 8 , Oct 31, 2005
        • 0 Attachment
          Biske, Todd wrote:
          > In the spirit of Gervas' suggestion to turn the discussions on SOA infrastructure,
          >I'm interested in what the group has to say about the role of MOM in a
          Web-Services based SOA.
          >From an architectural perspective (i.e. technology indepedent), I don't think
          there's any
          >argument that queuing systems are a key part of an SOA. Once we actually try
          to implement
          >the infrastructure required for an SOA, and build our services on top of it,
          we run into
          >technology-specific issues. One high up on my list is queuing systems.
          >
          > In my experience, there are two primary types of service invocations. The first is a push model.

          > There are several questions that arise around the pull model:
          > * What's the proper way of exposing these services?
          > * Do we need a standard wire protocol for talking to a queue?
          > * When will queuing systems support SOAP natively? Right now, we have mediation technology for SOAP/HTTP where everything is migrating toward policies based upon the SOAP envelope, not the HTTP envelope. JMS providers focus on their proprietary JMS envelope (i.e. JMS properties) not on the SOAP envelope.
          > * What if queuing providers exposed a Web Service for publishing to a queue? What would this do to the functional model?
          >
          > I've yet to see anyone really attack these problems head on.

          This is a scarry statement. Are there really people going around talking about
          SOA who have not deployed systems using Linda spaces such as the Javaspaces
          implementation in the Jini platform? There is some things to learn by at least
          reading about Jini technology. There are no new books on the jini2.0 and later
          security changes. But the basic of Jini and javaspaces are clearly explained in
          the old books and on the web.

          For those who have no spaces experience:

          A space provides an excellent mechanism for exactly what you describe. The
          basic scenario is

          1. N Workers are performing reads from the space, blocking when not
          data is available.
          2. Applications put work items in the space.
          3. A worker's read returns the item, the worker does the job and
          puts back a response.
          4. The application performs a read on the space for its results
          5. The application gets its results and proceeds.

          Identifying the response for a specific work item is part of the detail that you
          decide on. One way is:

          1. write an object with a transaction in it, along with the work
          into the space first.
          2. perform a read under the same transaction, waiting for your result
          3. worker writes result to space using your transaction.

          This lets you see the transaction lease expiration as an indication that your
          work will not be performed for you so that you can re-request your work.

          You can put a magic cookie in your work item that the result is also written
          with so that you can identify the specific response you want.

          Queues are interesting, but only for more single focused data transfers.
          Multi-in/Multi-out scenarios work much better with a space, instead.

          Gregg Wonderly
        • Anne Thomas Manes
          See also WS-Eventing. http://www-128.ibm.com/developerworks/webservices/library/specification/ws-eventing/ Consider Microsoft s Indigo (now WCF) programming
          Message 4 of 8 , Nov 1, 2005
          • 0 Attachment
            See also WS-Eventing.
            http://www-128.ibm.com/developerworks/webservices/library/specification/ws-eventing/

            Consider Microsoft's Indigo (now WCF) programming model -- it provides a common programming model that support request/response and event/queuing.

            From my perspective, an application shouldn't have to work directly with a queue. It should be able to send a message to an endpoint, and the endpoint should be able to accept it syncronously or asynchronously based on its current load and its policies. The sending application should use WS-Addressing to indicate its reply-to address.

            The technology obviously needs to catch up with the concepts, but I think that's where things are headed. Two years from now, I see no reason to continue to use propriatery MOM protocols except in support of legacy applications.

            Anne

            On 10/31/05, Paul Fremantle <pzfreo@...> wrote:
            Todd

            Firstly, good post. I agree this is a highly interesting and relevant discussion. I think the whole SOAP/JMS is basically a slight red herring, because it mixes up transport with semantics.T

             As you point out, there is a need for Web Services to support pull semantics as well as push semantics. For example, the submission by IBM of WS-Polling to the W3C ( http://www.w3.org/Submission/ws-polling/) creates an option to loosely couple services in time and directionality.

            The other relevant option is the Amazon Simple Queueing Service, http://www.amazon.com/gp/browse.html/104-4790757-2434363?_encoding=UTF8&node=13584001&no=13584171 , which provides  a WS mapping to a queueing paradigm.

            Both these options should be composable with reliability, and composable with SOAP transports, making a more flexible approach to choosing the right model (transport, QoS and semantic) compared to a JMS solution.

            Finally, I think that one thing that would be immensely useful would be a mapping from existing queueing models such as JMS into SOAP+RM+ a WSDL definition of queue transport. This would allow reliable interoperable bridging over SOAP/HTTP between JMS implementations which would be hugely valuable.

            Paul



            On 10/31/05, Biske, Todd < bisketa@...> wrote:

            In the spirit of Gervas' suggestion to turn the discussions on SOA infrastructure, I'm interested in what the group has to say about the role of MOM in a Web-Services based SOA. From an architectural perspective ( i.e. technology indepedent), I don't think there's any argument that queuing systems are a key part of an SOA.  Once we actually try to implement the infrastructure required for an SOA, and build our services on top of it, we run into technology-specific issues.  One high up on my list is queuing systems.

            In my experience, there are two primary types of service invocations. The first is a push model.  The service consumer pushes the request to a service consumer, and blocks for a response.  Infrastructure is designed to handle some peak level, and blocking may occur for some amount of time if the number of concurrent requests exceeds the number of handlers available.   The second is a pull model.  In this case, the service consumer pushes the request to a queue, and service providers pull the requests off as they have handlers available.  A debate in this scenario is whether there ever can be a service response, as certainly some vendors have allowed the possibility with proprietary JMS endpoints in WSDL.  My preference is to treat all of these as fire and forget services.  Any message produced as a result should be viewed as a business event rather than as a service response.   My definition of an event versus a service message is that the service consumer has an expectation that some processing will occur with a service message, while an event has no implied processing. 

            There are several questions that arise around the pull model:

            • What's the proper way of exposing these services?
            • Do we need a standard wire protocol for talking to a queue? 
            • When will queuing systems support SOAP natively?  Right now, we have mediation technology for SOAP/HTTP where everything is migrating toward policies based upon the SOAP envelope, not the HTTP envelope.  JMS providers focus on their proprietary JMS envelope ( i.e. JMS properties) not on the SOAP envelope.
            • What if queuing providers exposed a Web Service for publishing to a queue?  What would this do to the functional model? 

            I've yet to see anyone really attack these problems head on.  While the ESB solutions built on top of a MOM do address this, they're all proprietary solutions.  The only option that has some appeal is to utilize an HTTP to JMS/MQ/MSMQ bridge, provided that you accept my premise that all of these services are one-way invocations.  While this would address things from the consumer perspective (once WS-RM has broad support), it doesn't quite fix things on the provider perspective.  We still don't have a good answer for how this service should be exposed by the provider. 

            Thoughts?
            Todd Biske
            Software Infrastructure Engineering
            A.G. Edwards Technology Group, Inc.
            V:(314) 955-6254 F:(314) 955-4055 E:todd.biske@...



            -------------------------------------------------------------------------------------
            A.G. Edwards & Sons' outgoing and incoming e-mails are electronically
            archived and subject to review and/or disclosure to someone other
            than the recipient.

            -------------------------------------------------------------------------------------


            SPONSORED LINKS
            Service-oriented architecture Computer monitoring software Computer and internet software
            Free computer monitoring software


            YAHOO! GROUPS LINKS






            SPONSORED LINKS
            Service-oriented architecture Computer monitoring software Computer and internet software
            Free computer monitoring software


            YAHOO! GROUPS LINKS




          • Gervas Douglas (gmail)
            Linda/tuple spaces as a paradigm has certain inherent advantages including underlying decoupling (i.e. going beyond loose coupling) whilst allowing the
            Message 5 of 8 , Nov 1, 2005
            • 0 Attachment
              Linda/tuple spaces as a paradigm has certain inherent advantages including
              underlying decoupling (i.e. going beyond loose coupling) whilst allowing the
              implementation of coupling at a higher level to whatever degree of
              tightness or synchroncity is required. It is also both inherently scalable
              and failover in nature. Have any of you architects in middleware companies
              considered implementing it as the underlying connectivity mechanism for an
              ESB?

              Gervas

              ----- Original Message -----
              From: "Gregg Wonderly" <gergg@...>
              To: <service-orientated-architecture@yahoogroups.com>
              Sent: Tuesday, November 01, 2005 3:40 AM
              Subject: Re: [service-orientated-architecture] Role of MOM in a Web Services
              based SOA


              > Biske, Todd wrote:
              > > In the spirit of Gervas' suggestion to turn the discussions on SOA
              infrastructure,
              > >I'm interested in what the group has to say about the role of MOM in a
              > Web-Services based SOA.
              > >From an architectural perspective (i.e. technology indepedent), I don't
              think
              > there's any
              > >argument that queuing systems are a key part of an SOA. Once we
              actually try
              > to implement
              > >the infrastructure required for an SOA, and build our services on top of
              it,
              > we run into
              > >technology-specific issues. One high up on my list is queuing systems.
              > >
              > > In my experience, there are two primary types of service invocations.
              The first is a push model.
              >
              > > There are several questions that arise around the pull model:
              > > * What's the proper way of exposing these services?
              > > * Do we need a standard wire protocol for talking to a queue?
              > > * When will queuing systems support SOAP natively? Right now, we have
              mediation technology for SOAP/HTTP where everything is migrating toward
              policies based upon the SOAP envelope, not the HTTP envelope. JMS providers
              focus on their proprietary JMS envelope (i.e. JMS properties) not on the
              SOAP envelope.
              > > * What if queuing providers exposed a Web Service for publishing to a
              queue? What would this do to the functional model?
              > >
              > > I've yet to see anyone really attack these problems head on.
              >
              > This is a scarry statement. Are there really people going around talking
              about
              > SOA who have not deployed systems using Linda spaces such as the
              Javaspaces
              > implementation in the Jini platform? There is some things to learn by at
              least
              > reading about Jini technology. There are no new books on the jini2.0 and
              later
              > security changes. But the basic of Jini and javaspaces are clearly
              explained in
              > the old books and on the web.
              >
              > For those who have no spaces experience:
              >
              > A space provides an excellent mechanism for exactly what you describe.
              The
              > basic scenario is
              >
              > 1. N Workers are performing reads from the space, blocking when not
              > data is available.
              > 2. Applications put work items in the space.
              > 3. A worker's read returns the item, the worker does the job and
              > puts back a response.
              > 4. The application performs a read on the space for its results
              > 5. The application gets its results and proceeds.
              >
              > Identifying the response for a specific work item is part of the detail
              that you
              > decide on. One way is:
              >
              > 1. write an object with a transaction in it, along with the work
              > into the space first.
              > 2. perform a read under the same transaction, waiting for your result
              > 3. worker writes result to space using your transaction.
              >
              > This lets you see the transaction lease expiration as an indication that
              your
              > work will not be performed for you so that you can re-request your work.
              >
              > You can put a magic cookie in your work item that the result is also
              written
              > with so that you can identify the specific response you want.
              >
              > Queues are interesting, but only for more single focused data transfers.
              > Multi-in/Multi-out scenarios work much better with a space, instead.
              >
              > Gregg Wonderly
              >
              >
              >
              >
              >
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
              >
            • Biske, Todd
              Anne wrote: From my perspective, an application shouldn t have to work directly with a queue. It should be able to send a message to an endpoint, and the
              Message 6 of 8 , Nov 1, 2005
              • 0 Attachment
                Anne wrote:
                From my perspective, an application shouldn't have to work directly with a queue. It should be able to send a message to an endpoint, and the endpoint should be able to accept it syncronously or asynchronously based on its current load and its policies. The sending application should use WS-Addressing to indicate its reply-to address.
                This is something I've considered quite a bit.  Any application server actually employs some degree of queueing.  The problem lies in when the "ack" is sent back to the client.  When utilizing a queue in the middle, the ack comes back when the message is received and persisted by the queue.  Within an app server using the typical HTTP paradigm, the ack wouldn't typically occur until the message is handed off to a handler.  So, as you suggest, the technology needs to change.  It would be great to see this in two years, although, I think it's likely that we'll see it first in the intermediary space (we already are with proprietary ESBs).  The challenge there is that having an intermediary with capabilities like WS-RM doesn't do you any good if the endpoints don't support it. 
                 
                Thanks for the discussion! 

                -tb 

                On 10/31/05, Paul Fremantle <pzfreo@...> wrote:
                Todd

                Firstly, good post. I agree this is a highly interesting and relevant discussion. I think the whole SOAP/JMS is basically a slight red herring, because it mixes up transport with semantics.T

                 As you point out, there is a need for Web Services to support pull semantics as well as push semantics. For example, the submission by IBM of WS-Polling to the W3C ( http://www.w3.org/Submission/ws-polling/) creates an option to loosely couple services in time and directionality.

                The other relevant option is the Amazon Simple Queueing Service, http://www.amazon.com/gp/browse.html/104-4790757-2434363?_encoding=UTF8&node=13584001&no=13584171 , which provides  a WS mapping to a queueing paradigm.

                Both these options should be composable with reliability, and composable with SOAP transports, making a more flexible approach to choosing the right model (transport, QoS and semantic) compared to a JMS solution.

                Finally, I think that one thing that would be immensely useful would be a mapping from existing queueing models such as JMS into SOAP+RM+ a WSDL definition of queue transport. This would allow reliable interoperable bridging over SOAP/HTTP between JMS implementations which would be hugely valuable.

                Paul



                On 10/31/05, Biske, Todd < bisketa@...> wrote:

                In the spirit of Gervas' suggestion to turn the discussions on SOA infrastructure, I'm interested in what the group has to say about the role of MOM in a Web-Services based SOA. From an architectural perspective ( i.e. technology indepedent), I don't think there's any argument that queuing systems are a key part of an SOA.  Once we actually try to implement the infrastructure required for an SOA, and build our services on top of it, we run into technology-specific issues.  One high up on my list is queuing systems.

                In my experience, there are two primary types of service invocations. The first is a push model.  The service consumer pushes the request to a service consumer, and blocks for a response.  Infrastructure is designed to handle some peak level, and blocking may occur for some amount of time if the number of concurrent requests exceeds the number of handlers available.   The second is a pull model.  In this case, the service consumer pushes the request to a queue, and service providers pull the requests off as they have handlers available.  A debate in this scenario is whether there ever can be a service response, as certainly some vendors have allowed the possibility with proprietary JMS endpoints in WSDL.  My preference is to treat all of these as fire and forget services.  Any message produced as a result should be viewed as a business event rather than as a service response.   My definition of an event versus a service message is that the service consumer has an expectation that some processing will occur with a service message, while an event has no implied processing. 

                There are several questions that arise around the pull model:

                • What's the proper way of exposing these services?
                • Do we need a standard wire protocol for talking to a queue? 
                • When will queuing systems support SOAP natively?  Right now, we have mediation technology for SOAP/HTTP where everything is migrating toward policies based upon the SOAP envelope, not the HTTP envelope.  JMS providers focus on their proprietary JMS envelope ( i.e. JMS properties) not on the SOAP envelope.
                • What if queuing providers exposed a Web Service for publishing to a queue?  What would this do to the functional model? 

                I've yet to see anyone really attack these problems head on.  While the ESB solutions built on top of a MOM do address this, they're all proprietary solutions.  The only option that has some appeal is to utilize an HTTP to JMS/MQ/MSMQ bridge, provided that you accept my premise that all of these services are one-way invocations.  While this would address things from the consumer perspective (once WS-RM has broad support), it doesn't quite fix things on the provider perspective.  We still don't have a good answer for how this service should be exposed by the provider. 

                Thoughts?
                Todd Biske
                Software Infrastructure Engineering
                A.G. Edwards Technology Group, Inc.
                V:(314) 955-6254 F:(314) 955-4055 E:todd.biske@...



                -------------------------------------------------------------------------------------
                A.G. Edwards & Sons' outgoing and incoming e-mails are electronically
                archived and subject to review and/or disclosure to someone other
                than the recipient.

                -------------------------------------------------------------------------------------


                SPONSORED LINKS
                Service-oriented architectureComputer monitoring softwareComputer and internet software
                Free computer monitoring software


                YAHOO! GROUPS LINKS






                SPONSORED LINKS
                Service-oriented architectureComputer monitoring softwareComputer and internet software
                Free computer monitoring software


                YAHOO! GROUPS LINKS




              • Vikas Deolaliker
                Todd, IMHO the relevant question should be Role of web services in a existing MOM environment . WS infrastructure can provide a bridge among multiple MOMs and
                Message 7 of 8 , Nov 1, 2005
                • 0 Attachment
                  Role of MOM in a Web Services based SOA

                   

                  Todd,

                   

                  IMHO the relevant question should be “Role of web services in a existing MOM environment”.

                   

                  WS infrastructure can provide a bridge among multiple MOMs and extend a MOM over WAN, Gateway MOM to other VANs or provide gatewaying services for native Web Services to access functionality that is using MOM.

                   

                  All of these products are on the roadmap of several startups today.

                   

                  Vikas

                   

                   


                  From: service-orientated-architecture@yahoogroups.com [mailto: service-orientated-architecture@yahoogroups.com ] On Behalf Of Biske, Todd
                  Sent: Monday, October 31, 2005 9:54 AM
                  To: service-orientated-architecture@yahoogroups.com
                  Subject: [service-orientated-architecture] Role of MOM in a Web Services based SOA

                   

                  In the spirit of Gervas’ suggestion to turn the discussions on SOA infrastructure, I’m interested in what the group has to say about the role of MOM in a Web-Services based SOA. From an architectural perspective (i.e. technology indepedent), I don’t think there’s any argument that queuing systems are a key part of an SOA.  Once we actually try to implement the infrastructure required for an SOA, and build our services on top of it, we run into technology-specific issues.  One high up on my list is queuing systems.

                  In my experience, there are two primary types of service invocations. The first is a push model.  The service consumer pushes the request to a service consumer, and blocks for a response.  Infrastructure is designed to handle some peak level, and blocking may occur for some amount of time if the number of concurrent requests exceeds the number of handlers available.   The second is a pull model.  In this case, the service consumer pushes the request to a queue, and service providers pull the requests off as they have handlers available.  A debate in this scenario is whether there ever can be a service response, as certainly some vendors have allowed the possibility with proprietary JMS endpoints in WSDL.  My preference is to treat all of these as fire and forget services.  Any message produced as a result should be viewed as a business event rather than as a service response.   My definition of an event versus a service message is that the service consumer has an expectation that some processing will occur with a service message, while an event has no implied processing. 

                  There are several questions that arise around the pull model:

                  • What’s the proper way of exposing these services?
                  • Do we need a standard wire protocol for talking to a queue? 
                  • When will queuing systems support SOAP natively?  Right now, we have mediation technology for SOAP/HTTP where everything is migrating toward policies based upon the SOAP envelope, not the HTTP envelope.  JMS providers focus on their proprietary JMS envelope (i.e. JMS properties) not on the SOAP envelope.
                  • What if queuing providers exposed a Web Service for publishing to a queue?  What would this do to the functional model? 

                   

                  I’ve yet to see anyone really attack these problems head on.  While the ESB solutions built on top of a MOM do address this, they’re all proprietary solutions.  The only option that has some appeal is to utilize an HTTP to JMS/MQ/MSMQ bridge, provided that you accept my premise that all of these services are one-way invocations.  While this would address things from the consumer perspective (once WS-RM has broad support), it doesn’t quite fix things on the provider perspective.  We still don’t have a good answer for how this service should be exposed by the provider. 

                  Thoughts?
                  Todd Biske
                  Software Infrastructure Engineering
                  A.G. Edwards Technology Group, Inc.
                  V:(314) 955-6254 F:(314) 955-4055 E:todd.biske@...



                  -------------------------------------------------------------------------------------
                  A.G. Edwards & Sons' outgoing and incoming e-mails are electronically
                  archived and subject to review and/or disclosure to someone other
                  than the recipient.

                  -------------------------------------------------------------------------------------

                Your message has been successfully submitted and would be delivered to recipients shortly.