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

Services and Operations - Take 2

Expand Messages
  • Andrew Herbst
    Greetings Again: Thanks for the many responses to my question about services and operations.  I am still unclear, though, so I would like to ask a
    Message 1 of 15 , Mar 3, 2010

      Greetings Again:

      Thanks for the many responses to my question about services and operations.  I am still unclear, though, so I would like to ask a follow-up.  First, let me say that I believe I have no trouble at all with the concept of a service as a “container”.  Let me try again building on some of your answers:

      Some of you have asserted that the basis for grouping operations together in a service really is grounded in “life-cycle management” concerns – as one of you wrote “You want to bundle things that are likely to change as a independent unit”.  Fair enough.  Since a service functions as a “domain of control” (as another of you wrote), it is sensible that you want to group operations together based on how they are likely to change.  Again, I think I get this.

      But I would think that there is something more foundational at play here.  The reason why certain operations change together is that they are functionally cohesive – what one does is related to what another does through some higher-order business function that they collectively realize.  In short, it is functional cohesiveness that ties operations together, that undergirds why they tend to change together, and why they therefore should be grouped in a single service.

      I guess what I am asserting is that functional complementarity in respect to provision of a higher order function of interest to consumers is the real basis for grouping operations together into  a service.  Since functionally complementary operations tend to change together, and since a service provides the “control infrastructure” for accessing the operations, the payoff is that when all these related operations change, you only need to change a single service.

      Now having said all this, I do not believe that any of you directly addressed this assertion of mine from my earlier post:

      By contrast, the scope of functionality provided by an operation is determined by consumer-provider interactions - each operation corresponds to one discrete consumer-provider interaction

      Is this statement in any sense correct?

      Thanks again,

      Andrew Herbst


    • Michael Poulin
      - does not sound to me as a correct wording: because
      Message 2 of 15 , Mar 3, 2010
        <<the scope of functionality provided by an operation is determined by consumer-provider interactions>> - does not sound to me as a correct wording: because the scope of functionality provided by an operation is determined by the Service Description. Real functionality of the service may be not fully visible through the operation, which is just a trigger. The consumer-provider interactions are agreed based on Service Description and documented in the Service Contracts. The latter can exist with no real interaction between the consumer and the service. That is, if inr statement in question 'provider'='service', then the statement is not fully correct; if <<consumer-provider interactions>> stand for the agreement resulted in Service Contract, the statement is correct.

        <<each operation corresponds to one discrete consumer-provider interaction>> - see above. Also, one interaction between the consumer and the service corresponds to one operation invocation. At the same time, one operation ay be invoked by multiple consumers.

        However, the statement that <<
        you want to group operations together based on how they are likely to change>> is not the key for grouping, IMO. The keys are cohesiveness and integral dependency. Which of the grouped operation will change and whether other operations in the group must be change in response to the initial change is simply unknown, there is no mandatory chain reaction. That is, we cannot say they MUST change but we can say they MAY change together.      

        The conclusion <<
        Since functionally complementary operations tend to change together>> is not justified, IMO; I would avoid such assumption.

        Under the explained constraints, I do agree with <<In short, it is functional cohesiveness that ties operations together>>

        - Michael


        From: Andrew Herbst <herbst_andrew@...>
        To: service-orientated-architecture@yahoogroups.com
        Sent: Wed, March 3, 2010 5:07:37 PM
        Subject: [service-orientated-architecture] Services and Operations - Take 2

         

        Greetings Again:

        Thanks for the many responses to my question about services and operations.  I am still unclear, though, so I would like to ask a follow-up.  First, let me say that I believe I have no trouble at all with the concept of a service as a “container”.  Let me try again building on some of your answers:

        Some of you have asserted that the basis for grouping operations together in a service really is grounded in “life-cycle management” concerns – as one of you wrote “You want to bundle things that are likely to change as a independent unit”.  Fair enough.  Since a service functions as a “domain of control” (as another of you wrote), it is sensible that you want to group operations together based on how they are likely to change.  Again, I think I get this.

        But I would think that there is something more foundational at play here.  The reason why certain operations change together is that they are functionally cohesive – what one does is related to what another does through some higher-order business function that they collectively realize.  In short, it is functional cohesiveness that ties operations together, that undergirds why they tend to change together, and why they therefore should be grouped in a single service.

        I guess what I am asserting is that functional complementarity in respect to provision of a higher order function of interest to consumers is the real basis for grouping operations together into  a service.  Since functionally complementary operations tend to change together, and since a service provides the “control infrastructure” for accessing the operations, the payoff is that when all these related operations change, you only need to change a single service.

        Now having said all this, I do not believe that any of you directly addressed this assertion of mine from my earlier post:

        By contrast, the scope of functionality provided by an operation is determined by consumer-provider interactions - each operation corresponds to one discrete consumer-provider interaction

        Is this statement in any sense correct?

        Thanks again,

        Andrew Herbst



      • Anders Tell
        ... Andrew, this is an interesting issue, how to bundle communicative acts as services (and operations). There exists three powerful aspects that can be used
        Message 3 of 15 , Mar 19, 2010

          By contrast, the scope of functionality provided by an operation is determined by consumer-provider interactions - each operation corresponds to one discrete consumer-provider interaction



          Andrew, this is an interesting issue, how to bundle communicative acts as services (and operations).

          There exists three powerful aspects that can be used in/guiding such partitioning exercise

          * Conversations

          * Lifecycle(s) of entites that are of concerns to consumer and supplier
            (see ISO 15288 for interesting lifecycles)


          * Commitments, duties attributed to either consumer or producer.
             such as Delivery of Goods and Payments (reciprocity)
            (see REA for examples)

          Above is presented from a business viewpoint (i.e. abstract)

          /anders w. tell
          Senior ESA Architect
          Standard strategist.
        • Michael Poulin
          Anders, can you explain ? Is it meant one type of interaction? How an interaction
          Message 4 of 15 , Mar 23, 2010
            Anders, can you explain <<each operation corresponds to one discrete consumer-provider interaction>>? Is it meant one type of interaction? How an 'interaction' is defined in this context? If I sent 2 different messages to the same operation, it it a case of 2 interactions because I communicated two times or because I communicated with two different messages?

            - Michael



            From: Anders Tell <anderst@...>
            To: service-orientated-architecture@yahoogroups.com
            Sent: Fri, March 19, 2010 3:29:56 PM
            Subject: Re: [service-orientated-architecture] Services and Operations - Take 2

             


            By contrast, the scope of functionality provided by an operation is determined by consumer-provider interactions - each operation corresponds to one discrete consumer-provider interaction



            Andrew, this is an interesting issue, how to bundle communicative acts as services (and operations).

            There exists three powerful aspects that can be used in/guiding such partitioning exercise

            * Conversations

            * Lifecycle(s) of entites that are of concerns to consumer and supplier
              (see ISO 15288 for interesting lifecycles)


            * Commitments, duties attributed to either consumer or producer.
               such as Delivery of Goods and Payments (reciprocity)
              (see REA for examples)

            Above is presented from a business viewpoint (i.e. abstract)

            /anders w. tell
            Senior ESA Architect
            Standard strategist.

          • Anders Tell
            Michael, Im not sure I should answer directly since i wanst the originator of the statement. But I can give some insights from the EDI world. There there the
            Message 5 of 15 , Mar 24, 2010
              Michael, Im not sure I should answer directly since i wanst the originator of the statement.

              But I can give some insights from the EDI world. There there the notion of retries and identity of message. So it depends on the specification of the interaction what the outcomes should be. If retry is relevant then resending a message (same id) more than once, in the same interaction,is possible

              /anders


              On Mar 23, 2010, at 9:49 PM, Michael Poulin wrote:

               

              Anders, can you explain <<each operation corresponds to one discrete consumer-provider interaction>>? Is it meant one type of interaction? How an 'interaction' is defined in this context? If I sent 2 different messages to the same operation, it it a case of 2 interactions because I communicated two times or because I communicated with two different messages?

              - Michael



              From: Anders Tell <anderst@toolsmiths. se>
              To: service-orientated- architecture@ yahoogroups. com
              Sent: Fri, March 19, 2010 3:29:56 PM
              Subject: Re: [service-orientated -architecture] Services and Operations - Take 2

               


              By contrast, the scope of functionality provided by an operation is determined by consumer-provider interactions - each operation corresponds to one discrete consumer-provider interaction



              Andrew, this is an interesting issue, how to bundle communicative acts as services (and operations).

              There exists three powerful aspects that can be used in/guiding such partitioning exercise

              * Conversations

              * Lifecycle(s) of entites that are of concerns to consumer and supplier
                (see ISO 15288 for interesting lifecycles)


              * Commitments, duties attributed to either consumer or producer.
                 such as Delivery of Goods and Payments (reciprocity)
                (see REA for examples)

              Above is presented from a business viewpoint (i.e. abstract)

              /anders w. tell
              Senior ESA Architect
              Standard strategist.



            • Ashraf Galal
              Usually, when designing a business service, we have to maximize re-usability by designing its operations in a coarse-grained fashion. For example, when
              Message 6 of 15 , Mar 24, 2010
                Usually, when designing a business service, we have to maximize
                re-usability by designing its operations in a coarse-grained fashion.
                For example, when retrieving customer data, almost more than 100
                attributes, for example, are returned by the service, when then can be
                filtered by the client side.
                The alternative would have been to perform filtering within the service,
                which would have restricted re-usability.
                I think this is what he meant by his question.
                All the best

                Ashraf Galal



                Michael Poulin wrote:
                >
                > Anders, can you explain <</each operation corresponds to one discrete
                > consumer-provider interaction/>>? Is it meant one type of interaction?
                > How an 'interaction' is defined in this context? If I sent 2 different
                > messages to the same operation, it it a case of 2 interactions because
                > I communicated two times or because I communicated with two different
                > messages?
                >
                > - Michael
                >
                >
                > ------------------------------------------------------------------------
                > *From:* Anders Tell <anderst@...>
                > *To:* service-orientated-architecture@yahoogroups.com
                > *Sent:* Fri, March 19, 2010 3:29:56 PM
                > *Subject:* Re: [service-orientated-architecture] Services and
                > Operations - Take 2
                >
                >
                >
                >
                >> /By contrast, the scope of functionality provided by an operation is
                >> determined by consumer-provider interactions - each operation
                >> corresponds to one discrete consumer-provider interaction/
                >>
                >
                >
                > Andrew, this is an interesting issue, how to bundle communicative acts
                > as services (and operations).
                >
                > There exists three powerful aspects that can be used in/guiding such
                > partitioning exercise
                >
                > * Conversations
                >
                > * Lifecycle(s) of entites that are of concerns to consumer and supplier
                > (see ISO 15288 for interesting lifecycles)
                >
                >
                > * Commitments, duties attributed to either consumer or producer.
                > such as Delivery of Goods and Payments (reciprocity)
                > (see REA for examples)
                >
                > Above is presented from a business viewpoint (i.e. abstract)
                >
                > /anders w. tell
                > Senior ESA Architect
                > Standard strategist.
                >
                >
              • Michael Poulin
                I would disagree that filtering in the service restricts reusability or a use by multiple clients (which is not the same thing to me) in any way. The
                Message 7 of 15 , Mar 28, 2010
                  I would disagree that filtering in the service restricts 'reusability'  or a use by multiple clients (which is not the same thing to me) in any way. The filtering is the objective client's characteristic related to Entitlement. Each client must have its own View on the same data (single source of truth); it is a silly thing to move all 100 attributes to the one who needs only 3 out of them, IMO. Filtering in the service based on client entitlement or approved interests only adds flexibility to the service, and, thus, increases is client audience.

                  But all this does not relate to the original question - what was an interaction with the service in the Anders' interpretation. 

                  - Michael


                  From: Ashraf Galal <ashrafwg@...>
                  To: service-orientated-architecture@yahoogroups.com
                  Sent: Wed, March 24, 2010 11:48:32 AM
                  Subject: Re: [service-orientated-architecture] Services and Operations - Take 2

                   

                  Usually, when designing a business service, we have to maximize
                  re-usability by designing its operations in a coarse-grained fashion.
                  For example, when retrieving customer data, almost more than 100
                  attributes, for example, are returned by the service, when then can be
                  filtered by the client side.
                  The alternative would have been to perform filtering within the service,
                  which would have restricted re-usability.
                  I think this is what he meant by his question.
                  All the best

                  Ashraf Galal

                  Michael Poulin wrote:

                  >
                  > Anders, can you explain <</each operation corresponds to one discrete
                  > consumer-provider interaction/ >>? Is it meant one type of interaction?
                  > How an 'interaction' is defined in this context? If I sent 2 different
                  > messages to the same operation, it it a case of 2 interactions because
                  > I communicated two times or because I communicated with two different
                  > messages?
                  >
                  > - Michael
                  >
                  >
                  > ------------ --------- --------- --------- --------- --------- -
                  > *From:* Anders Tell <anderst@toolsmiths. se>
                  > *To:* service-orientated- architecture@ yahoogroups. com
                  > *Sent:* Fri, March 19, 2010 3:29:56 PM
                  > *Subject:* Re: [service-orientated -architecture] Services and
                  > Operations - Take 2
                  >
                  >
                  >
                  >
                  >> /By contrast, the scope of functionality provided by an operation is
                  >> determined by consumer-provider interactions - each operation
                  >> corresponds to one discrete consumer-provider interaction/
                  >>
                  >
                  >
                  > Andrew, this is an interesting issue, how to bundle communicative acts
                  > as services (and operations).
                  >
                  > There exists three powerful aspects that can be used in/guiding such
                  > partitioning exercise
                  >
                  > * Conversations
                  >
                  > * Lifecycle(s) of entites that are of concerns to consumer and supplier
                  > (see ISO 15288 for interesting lifecycles)
                  >
                  >
                  > * Commitments, duties attributed to either consumer or producer.
                  > such as Delivery of Goods and Payments (reciprocity)
                  > (see REA for examples)
                  >
                  > Above is presented from a business viewpoint (i.e. abstract)
                  >
                  > /anders w. tell
                  > Senior ESA Architect
                  > Standard strategist.
                  >
                  >


                • Steve Jones
                  I m not sure it is silly to ship 100 attributes out to the mediation layer from a service. Now at the mediation layer (execution context type of thing) these
                  Message 8 of 15 , Mar 28, 2010
                    I'm not sure it is silly to ship 100 attributes out to the mediation layer from a service.  Now at the mediation layer (execution context type of thing) these could be stripped because the consumer doesn't require them but I'm not sure why a service should worry about the specific mode of consumption in terms of the number of attributes.  If the filter is done based on the consumer requests and the filter is the responsibility of the consumer then they can take on more attributes without requiring a modification to the service.

                    Steve


                    On 28 March 2010 14:34, Michael Poulin <m3poulin@...> wrote:
                     

                    I would disagree that filtering in the service restricts 'reusability'  or a use by multiple clients (which is not the same thing to me) in any way. The filtering is the objective client's characteristic related to Entitlement. Each client must have its own View on the same data (single source of truth); it is a silly thing to move all 100 attributes to the one who needs only 3 out of them, IMO. Filtering in the service based on client entitlement or approved interests only adds flexibility to the service, and, thus, increases is client audience.

                    But all this does not relate to the original question - what was an interaction with the service in the Anders' interpretation. 

                    - Michael


                    From: Ashraf Galal <ashrafwg@...>Sent: Wed, March 24, 2010 11:48:32 AM

                    Subject: Re: [service-orientated-architecture] Services and Operations - Take 2

                     

                    Usually, when designing a business service, we have to maximize
                    re-usability by designing its operations in a coarse-grained fashion.
                    For example, when retrieving customer data, almost more than 100
                    attributes, for example, are returned by the service, when then can be
                    filtered by the client side.
                    The alternative would have been to perform filtering within the service,
                    which would have restricted re-usability.
                    I think this is what he meant by his question.
                    All the best

                    Ashraf Galal

                    Michael Poulin wrote:
                    >
                    > Anders, can you explain <</each operation corresponds to one discrete
                    > consumer-provider interaction/ >>? Is it meant one type of interaction?
                    > How an 'interaction' is defined in this context? If I sent 2 different
                    > messages to the same operation, it it a case of 2 interactions because
                    > I communicated two times or because I communicated with two different
                    > messages?
                    >
                    > - Michael
                    >
                    >
                    > ------------ --------- --------- --------- --------- --------- -
                    > *From:* Anders Tell <anderst@toolsmiths. se>
                    > *To:* service-orientated- architecture@ yahoogroups. com
                    > *Sent:* Fri, March 19, 2010 3:29:56 PM
                    > *Subject:* Re: [service-orientated -architecture] Services and
                    > Operations - Take 2
                    >
                    >
                    >
                    >
                    >> /By contrast, the scope of functionality provided by an operation is
                    >> determined by consumer-provider interactions - each operation
                    >> corresponds to one discrete consumer-provider interaction/
                    >>
                    >
                    >
                    > Andrew, this is an interesting issue, how to bundle communicative acts
                    > as services (and operations).
                    >
                    > There exists three powerful aspects that can be used in/guiding such
                    > partitioning exercise
                    >
                    > * Conversations
                    >
                    > * Lifecycle(s) of entites that are of concerns to consumer and supplier
                    > (see ISO 15288 for interesting lifecycles)
                    >
                    >
                    > * Commitments, duties attributed to either consumer or producer.
                    > such as Delivery of Goods and Payments (reciprocity)
                    > (see REA for examples)
                    >
                    > Above is presented from a business viewpoint (i.e. abstract)
                    >
                    > /anders w. tell
                    > Senior ESA Architect
                    > Standard strategist.
                    >
                    >



                  • Michael Poulin
                    Besides extra data moved between the service and an optional mediation layer, there are also security considerations. One of the sins of the use of a mediation
                    Message 9 of 15 , Mar 29, 2010
                      Besides extra data moved between the service and an optional mediation layer, there are also security considerations. One of the sins of the use of a mediation layer for 'filtering' is the violation of the security golden rule - if data is not needed it may not leave its secured store. This means that the data may not leave either the service side or even the database (I wrote an article - Entitlement to Data - about this in 2006 and my method was taken by BEA for their security solution)

                      If you delegate 'filtering' to the intermediary, you are making the intermediary the mandatory part of your SO solution. I am against such constraint.

                      A business service should not worry <<worry about the specific mode of consumption in terms of the number of attributes>>, this is the worry of an Entitlement Service. Also, a business service may offer a feature of filtering-on-demand (<<the filter is done based on the consumer requests>>)

                      - Michael


                      From: Steve Jones <jones.steveg@...>
                      To: service-orientated-architecture@yahoogroups.com
                      Sent: Mon, March 29, 2010 5:06:41 AM
                      Subject: Re: [service-orientated-architecture] Services and Operations - Take 2

                       

                      I'm not sure it is silly to ship 100 attributes out to the mediation layer from a service.  Now at the mediation layer (execution context type of thing) these could be stripped because the consumer doesn't require them but I'm not sure why a service should worry about the specific mode of consumption in terms of the number of attributes.  If the filter is done based on the consumer requests and the filter is the responsibility of the consumer then they can take on more attributes without requiring a modification to the service.

                      Steve


                      On 28 March 2010 14:34, Michael Poulin <m3poulin@yahoo. com> wrote:
                       

                      I would disagree that filtering in the service restricts 'reusability'  or a use by multiple clients (which is not the same thing to me) in any way. The filtering is the objective client's characteristic related to Entitlement. Each client must have its own View on the same data (single source of truth); it is a silly thing to move all 100 attributes to the one who needs only 3 out of them, IMO. Filtering in the service based on client entitlement or approved interests only adds flexibility to the service, and, thus, increases  is client audience.

                      But all this does not relate to the original question - what was an interaction with the service in the Anders' interpretation. 

                      - Michael


                      From: Ashraf Galal <ashrafwg@gmail. com>Sent: Wed, March 24, 2010 11:48:32 AM

                      Subject: Re: [service-orientated -architecture] Services and Operations - Take 2

                       

                      Usually, when designing a business service, we have to maximize
                      re-usability by designing its operations in a coarse-grained fashion.
                      For example, when retrieving customer data, almost more than 100
                      attributes, for example, are returned by the service, when then can be
                      filtered by the client side.
                      The alternative would have been to perform filtering within the service,
                      which would have restricted re-usability.
                      I think this is what he meant by his question.
                      All the best

                      Ashraf Galal

                      Michael Poulin wrote:
                      >
                      > Anders, can you explain <</each operation corresponds to one discrete
                      > consumer-provider interaction/ >>? Is it meant one type of interaction?
                      > How an 'interaction' is defined in this context? If I sent 2 different
                      > messages to the same operation, it it a case of 2 interactions because
                      > I communicated two times or because I communicated with two different
                      > messages?
                      >
                      > - Michael
                      >
                      >
                      > ------------ --------- --------- --------- --------- --------- -
                      > *From:* Anders Tell <anderst@toolsmiths. se>
                      > *To:* service-orientated- architecture@ yahoogroups. com
                      > *Sent:* Fri, March 19, 2010 3:29:56 PM
                      > *Subject:* Re: [service-orientated -architecture] Services and
                      > Operations - Take 2
                      >
                      >
                      >
                      >
                      >> /By contrast, the scope of functionality provided by an operation is
                      >> determined by consumer-provider interactions - each operation
                      >> corresponds to one discrete consumer-provider interaction/
                      >>
                      >
                      >
                      > Andrew, this is an interesting issue, how to bundle communicative acts
                      > as services (and operations).
                      >
                      > There exists three powerful aspects that can be used in/guiding such
                      > partitioning exercise
                      >
                      > * Conversations
                      >
                      > * Lifecycle(s) of entites that are of concerns to consumer and supplier
                      > (see ISO 15288 for interesting lifecycles)
                      >
                      >
                      > * Commitments, duties attributed to either consumer or producer.
                      > such as Delivery of Goods and Payments (reciprocity)
                      > (see REA for examples)
                      >
                      > Above is presented from a business viewpoint (i.e. abstract)
                      >
                      > /anders w. tell
                      > Senior ESA Architect
                      > Standard strategist.
                      >
                      >




                    • Steve Jones
                      But isn t an Entitlement Service just a technical service which is part of the execution context? Steve
                      Message 10 of 15 , Mar 30, 2010
                        But isn't an Entitlement Service just a technical service which is part of the execution context?

                        Steve


                        On 29 March 2010 22:01, Michael Poulin <m3poulin@...> wrote:
                         

                        Besides extra data moved between the service and an optional mediation layer, there are also security considerations. One of the sins of the use of a mediation layer for 'filtering' is the violation of the security golden rule - if data is not needed it may not leave its secured store. This means that the data may not leave either the service side or even the database (I wrote an article - Entitlement to Data - about this in 2006 and my method was taken by BEA for their security solution)

                        If you delegate 'filtering' to the intermediary, you are making the intermediary the mandatory part of your SO solution. I am against such constraint.

                        A business service should not worry <<worry about the specific mode of consumption in terms of the number of attributes>>, this is the worry of an Entitlement Service. Also, a business service may offer a feature of filtering-on-demand (<<the filter is done based on the consumer requests>>)

                        - Michael


                        From: Steve Jones <jones.steveg@...>Sent: Mon, March 29, 2010 5:06:41 AM

                        Subject: Re: [service-orientated-architecture] Services and Operations - Take 2

                         

                        I'm not sure it is silly to ship 100 attributes out to the mediation layer from a service.  Now at the mediation layer (execution context type of thing) these could be stripped because the consumer doesn't require them but I'm not sure why a service should worry about the specific mode of consumption in terms of the number of attributes.  If the filter is done based on the consumer requests and the filter is the responsibility of the consumer then they can take on more attributes without requiring a modification to the service.

                        Steve


                        On 28 March 2010 14:34, Michael Poulin <m3poulin@yahoo. com> wrote:
                         

                        I would disagree that filtering in the service restricts 'reusability'  or a use by multiple clients (which is not the same thing to me) in any way. The filtering is the objective client's characteristic related to Entitlement. Each client must have its own View on the same data (single source of truth); it is a silly thing to move all 100 attributes to the one who needs only 3 out of them, IMO. Filtering in the service based on client entitlement or approved interests only adds flexibility to the service, and, thus, increases  is client audience.

                        But all this does not relate to the original question - what was an interaction with the service in the Anders' interpretation. 

                        - Michael


                        From: Ashraf Galal <ashrafwg@gmail. com>Sent: Wed, March 24, 2010 11:48:32 AM

                        Subject: Re: [service-orientated -architecture] Services and Operations - Take 2

                         

                        Usually, when designing a business service, we have to maximize
                        re-usability by designing its operations in a coarse-grained fashion.
                        For example, when retrieving customer data, almost more than 100
                        attributes, for example, are returned by the service, when then can be
                        filtered by the client side.
                        The alternative would have been to perform filtering within the service,
                        which would have restricted re-usability.
                        I think this is what he meant by his question.
                        All the best

                        Ashraf Galal

                        Michael Poulin wrote:
                        >
                        > Anders, can you explain <</each operation corresponds to one discrete
                        > consumer-provider interaction/ >>? Is it meant one type of interaction?
                        > How an 'interaction' is defined in this context? If I sent 2 different
                        > messages to the same operation, it it a case of 2 interactions because
                        > I communicated two times or because I communicated with two different
                        > messages?
                        >
                        > - Michael
                        >
                        >
                        > ------------ --------- --------- --------- --------- --------- -
                        > *From:* Anders Tell <anderst@toolsmiths. se>
                        > *To:* service-orientated- architecture@ yahoogroups. com
                        > *Sent:* Fri, March 19, 2010 3:29:56 PM
                        > *Subject:* Re: [service-orientated -architecture] Services and
                        > Operations - Take 2
                        >
                        >
                        >
                        >
                        >> /By contrast, the scope of functionality provided by an operation is
                        >> determined by consumer-provider interactions - each operation
                        >> corresponds to one discrete consumer-provider interaction/
                        >>
                        >
                        >
                        > Andrew, this is an interesting issue, how to bundle communicative acts
                        > as services (and operations).
                        >
                        > There exists three powerful aspects that can be used in/guiding such
                        > partitioning exercise
                        >
                        > * Conversations
                        >
                        > * Lifecycle(s) of entites that are of concerns to consumer and supplier
                        > (see ISO 15288 for interesting lifecycles)
                        >
                        >
                        > * Commitments, duties attributed to either consumer or producer.
                        > such as Delivery of Goods and Payments (reciprocity)
                        > (see REA for examples)
                        >
                        > Above is presented from a business viewpoint (i.e. abstract)
                        >
                        > /anders w. tell
                        > Senior ESA Architect
                        > Standard strategist.
                        >
                        >





                      • reamon943
                        Another view--the intermediary isn t doing the filtering, the consumer is. My POV is that the intermediary only hosts components on behalf of the consumers and
                        Message 11 of 15 , Mar 31, 2010
                          Another view--the intermediary isn't doing the filtering, the consumer is.

                          My POV is that the intermediary only hosts components on behalf of the consumers and providers. The intermediary doesn't have anything delegated to it.

                          -Rob

                          --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
                          >
                          > Besides extra data moved between the service and an optional mediation layer, there are also security considerations. One of the sins of the use of a mediation layer for 'filtering' is the violation of the security golden rule - if data is not needed it may not leave its secured store. This means that the data may not leave either the service side or even the database (I wrote an article - Entitlement to Data - about this in 2006 and my method was taken by BEA for their security solution)
                          >
                          > If you delegate 'filtering' to the intermediary, you are making the intermediary the mandatory part of your SO solution. I am against such constraint.
                          >
                          > A business service should not worry <<worry about the specific mode of consumption in terms of the number of attributes>>, this is the worry of an Entitlement Service. Also, a business service may offer a feature of filtering-on-demand (<<the filter is done based on the consumer requests>>)
                          >
                          > - Michael
                        • ramesh_nethi
                          Filtering in the service will also be along the lines of REST principles (i.e., let the Client negotiate and obtain a specified view of a given resource). Once
                          Message 12 of 15 , Apr 5, 2010
                            Filtering in the service will also be along the lines of REST principles (i.e., let the Client negotiate and obtain a specified view of a given resource). Once this is done as a service contract, it is matter of choice of the implementer to do it in an intermediary or in the real service itself.

                            Regards
                            Ramesh


                            --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
                            >
                            > Besides extra data moved between the service and an optional mediation layer, there are also security considerations. One of the sins of the use of a mediation layer for 'filtering' is the violation of the security golden rule - if data is not needed it may not leave its secured store. This means that the data may not leave either the service side or even the database (I wrote an article - Entitlement to Data - about this in 2006 and my method was taken by BEA for their security solution)
                            >
                            > If you delegate 'filtering' to the intermediary, you are making the intermediary the mandatory part of your SO solution. I am against such constraint.
                            >
                            > A business service should not worry <<worry about the specific mode of consumption in terms of the number of attributes>>, this is the worry of an Entitlement Service. Also, a business service may offer a feature of filtering-on-demand (<<the filter is done based on the consumer requests>>)
                            >
                            > - Michael
                            >
                            >
                            >
                            > ________________________________
                            > From: Steve Jones <jones.steveg@...>
                            > To: service-orientated-architecture@yahoogroups.com
                            > Sent: Mon, March 29, 2010 5:06:41 AM
                            > Subject: Re: [service-orientated-architecture] Services and Operations - Take 2
                            >
                            >
                            > I'm not sure it is silly to ship 100 attributes out to the mediation layer from a service. Now at the mediation layer (execution context type of thing) these could be stripped because the consumer doesn't require them but I'm not sure why a service should worry about the specific mode of consumption in terms of the number of attributes. If the filter is done based on the consumer requests and the filter is the responsibility of the consumer then they can take on more attributes without requiring a modification to the service.
                            >
                            > Steve
                            >
                            >
                            >
                            > On 28 March 2010 14:34, Michael Poulin <m3poulin@yahoo. com> wrote:
                            >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > > >
                            > >
                            > >>
                            > >
                            > >>
                            > >
                            > >I would disagree that filtering in the service restricts 'reusability' or a use by multiple clients (which is not the same thing to me) in any way. The filtering is the objective client's characteristic related to Entitlement. Each client must have its own View on the same data (single source of truth); it is a silly thing to move all 100 attributes to the one who needs only 3 out of them, IMO. Filtering in the service based on client entitlement or approved interests only adds flexibility to the service, and, thus, increases is client audience.
                            > >
                            > >
                            > >But all this does not relate to the original question - what was an interaction with the service in the Anders' interpretation.
                            > >
                            > >
                            > >- Michael
                            > >
                            > >
                            > >
                            > ________________________________
                            > From: Ashraf Galal <ashrafwg@gmail. com>
                            > >
                            > >To: service-orientated- architecture@ yahoogroups. com
                            > >Sent: Wed, March 24, 2010 11:48:32 AM
                            > >
                            > >Subject: Re: [service-orientated -architecture] Services and Operations - Take 2
                            > >
                            > >
                            > > >
                            > >
                            > >
                            > >>
                            > >
                            > >Usually, when designing a business service, we have to maximize
                            > >>re-usability by designing its operations in a coarse-grained fashion.
                            > >>For example, when retrieving customer data, almost more than 100
                            > >>attributes, for example, are returned by the service, when then can be
                            > >>filtered by the client side.
                            > >>The alternative would have been to perform filtering within the service,
                            > >>which would have restricted re-usability.
                            > >> I think this is what he meant by his question.
                            > >>All the best
                            > >
                            > >>Ashraf Galal
                            > >
                            > >>Michael Poulin wrote:
                            > >>>
                            > >>> Anders, can you explain <</each operation corresponds to one discrete
                            > >>> consumer-provider interaction/ >>? Is it meant one type of interaction?
                            > >>> How an 'interaction' is defined in this context? If I sent 2 different
                            > >>> messages to the same operation, it it a case of 2 interactions because
                            > >>> I communicated two times or because I communicated with two different
                            > >>> messages?
                            > >>>
                            > >>> - Michael
                            > >>>
                            > >>>
                            > >>> ------------ --------- --------- --------- --------- --------- -
                            > >>> *From:* Anders Tell <anderst@toolsmiths. se>
                            > >>> *To:* service-orientated- architecture@ yahoogroups. com
                            > >>> *Sent:* Fri, March 19, 2010 3:29:56 PM
                            > >>> *Subject:* Re: [service-orientated -architecture] Services and
                            > >>> Operations - Take 2
                            > >>>
                            > >>>
                            > >>>
                            > >>>
                            > >>>> /By contrast, the scope of functionality provided by an operation is
                            > >>>> determined by consumer-provider interactions - each operation
                            > >>>> corresponds to one discrete consumer-provider interaction/
                            > >>>>
                            > >>>
                            > >>>
                            > >>> Andrew, this is an interesting issue, how to bundle communicative acts
                            > >>> as services (and operations).
                            > >>>
                            > >>> There exists three powerful aspects that can be used in/guiding such
                            > >>> partitioning exercise
                            > >>>
                            > >>> * Conversations
                            > >>>
                            > >>> * Lifecycle(s) of entites that are of concerns to consumer and supplier
                            > >>> (see ISO 15288 for interesting lifecycles)
                            > >>>
                            > >>>
                            > >>> * Commitments, duties attributed to either consumer or producer.
                            > >>> such as Delivery of Goods and Payments (reciprocity)
                            > >>> (see REA for examples)
                            > >>>
                            > >>> Above is presented from a business viewpoint (i.e. abstract)
                            > >>>
                            > >>> /anders w. tell
                            > >>> Senior ESA Architect
                            > >>> Standard strategist.
                            > >>>
                            > >>>
                            > >
                            > >
                            > >
                            >
                          • Michael Poulin
                            Ramesh, I do not see how this directly relates to REST principles. However, I d like to notice that choice of the implementer to do it in an intermediary or
                            Message 13 of 15 , Apr 5, 2010
                              Ramesh, I do not see how this directly relates to REST principles. However, I'd like to notice that "choice of the implementer to do it in an intermediary or in the real service itself" does not appear as such to the consumer.

                              If filtering is assigned (according to the  Service Contract) to the service implementer (provider), then the consumer should not care how it is done; it always appears as in the service. The same is true about the reversal decision - consumer uses any means for the filtering and the service does not care about this subject - it is done inthe consumer. 

                              This comment relates to our discussion about 2 years old where we concluded that any intermediary (e.g., ESB) should be totally transparent for the consumer-service interaction, i.e. totally invisible to the opposite party. If the filter/ESB appears 'in clear' in between the consumer and the service and shields the service from the consumer, the latter should set the contract (Service Contract) with this ilter/ESB entity instead of the service because in this case the consumer does not know and does not need to know which actual service/provider would be used/chosen by the filter/ESB (intermediary).

                              - Michael


                              From: ramesh_nethi <rn.lists@...>
                              To: service-orientated-architecture@yahoogroups.com
                              Sent: Mon, April 5, 2010 1:13:35 PM
                              Subject: [service-orientated-architecture] Re: Services and Operations - Take 2

                               

                              Filtering in the service will also be along the lines of REST principles (i.e., let the Client negotiate and obtain a specified view of a given resource). Once this is done as a service contract, it is matter of choice of the implementer to do it in an intermediary or in the real service itself.

                              Regards
                              Ramesh

                              --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3poulin@.. .> wrote:
                              >
                              > Besides extra data moved between the service and an optional mediation layer, there are also security considerations. One of the sins of the use of a mediation layer for 'filtering' is the violation of the security golden rule - if data is not needed it may not leave its secured store. This means that the data may not leave either the service side or even the database (I wrote an article - Entitlement to Data - about this in 2006 and my method was taken by BEA for their security solution)
                              >
                              > If you delegate 'filtering' to the intermediary, you are making the intermediary the mandatory part of your SO solution. I am against such constraint.
                              >
                              > A business service should not worry <<worry about the specific mode of consumption in terms of the number of attributes>> , this is the worry of an Entitlement Service. Also, a business service may offer a feature of filtering-on- demand (<<the filter is done based on the consumer requests>>)
                              >
                              > - Michael
                              >
                              >
                              >
                              > ____________ _________ _________ __
                              > From: Steve Jones <jones.steveg@ ...>
                              > To: service-orientated- architecture@ yahoogroups. com
                              > Sent: Mon, March 29, 2010 5:06:41 AM
                              > Subject: Re: [service-orientated -architecture] Services and Operations - Take 2
                              >
                              >
                              > I'm not sure it is silly to ship 100 attributes out to the mediation layer from a service. Now at the mediation layer (execution context type of thing) these could be stripped because the consumer doesn't require them but I'm not sure why a service should worry about the specific mode of consumption in terms of the number of attributes. If the filter is done based on the consumer requests and the filter is the responsibility of the consumer then they can take on more attributes without requiring a modification to the service.
                              >
                              > Steve
                              >
                              >
                              >
                              > On 28 March 2010 14:34, Michael Poulin <m3poulin@yahoo. com> wrote:
                              >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > > >
                              > >
                              > >>
                              > >
                              > >>
                              > >
                              > >I would disagree that filtering in the service restricts 'reusability' or a use by multiple clients (which is not the same thing to me) in any way. The filtering is the objective client's characteristic related to Entitlement. Each client must have its own View on the same data (single source of truth); it is a silly thing to move all 100 attributes to the one who needs only 3 out of them, IMO. Filtering in the service based on client entitlement or approved interests only adds flexibility to the service, and, thus, increases is client audience.
                              > >
                              > >
                              > >But all this does not relate to the original question - what was an interaction with the service in the Anders' interpretation.
                              > >
                              > >
                              > >- Michael
                              > >
                              > >
                              > >
                              > ____________ _________ _________ __
                              > From: Ashraf Galal <ashrafwg@gmail. com>
                              > >
                              > >To: service-orientated- architecture@ yahoogroups. com
                              > >Sent: Wed, March 24, 2010 11:48:32 AM
                              > >
                              > >Subject: Re: [service-orientated -architecture] Services and Operations - Take 2
                              > >
                              > >
                              > > >
                              > >
                              > >
                              > >>
                              > >
                              > >Usually, when designing a business service, we have to maximize
                              > >>re-usability by designing its operations in a coarse-grained fashion.
                              > >>For example, when retrieving customer data, almost more than 100
                              > >>attributes, for example, are returned by the service, when then can be
                              > >>filtered by the client side.
                              > >>The alternative would have been to perform filtering within the service,
                              > >>which would have restricted re-usability.
                              > >> I think this is what he meant by his question.
                              > >>All the best
                              > >
                              > >>Ashraf Galal
                              > >
                              > >>Michael Poulin wrote:
                              > >>>
                              > >>> Anders, can you explain <</each operation corresponds to one discrete
                              > >>> consumer-provider interaction/ >>? Is it meant one type of interaction?
                              > >>> How an 'interaction' is defined in this context? If I sent 2 different
                              > >>> messages to the same operation, it it a case of 2 interactions because
                              > >>> I communicated two times or because I communicated with two different
                              > >>> messages?
                              > >>>
                              > >>> - Michael
                              > >>>
                              > >>>
                              > >>> ------------ --------- --------- --------- --------- --------- -
                              > >>> *From:* Anders Tell <anderst@toolsmiths . se>
                              > >>> *To:* service-orientated- architecture@ yahoogroups. com
                              > >>> *Sent:* Fri, March 19, 2010 3:29:56 PM
                              > >>> *Subject:* Re: [service-orientated -architecture] Services and
                              > >>> Operations - Take 2
                              > >>>
                              > >>>
                              > >>>
                              > >>>
                              > >>>> /By contrast, the scope of functionality provided by an operation is
                              > >>>> determined by consumer-provider interactions - each operation
                              > >>>> corresponds to one discrete consumer-provider interaction/
                              > >>>>
                              > >>>
                              > >>>
                              > >>> Andrew, this is an interesting issue, how to bundle communicative acts
                              > >>> as services (and operations).
                              > >>>
                              > >>> There exists three powerful aspects that can be used in/guiding such
                              > >>> partitioning exercise
                              > >>>
                              > >>> * Conversations
                              > >>>
                              > >>> * Lifecycle(s) of entites that are of concerns to consumer and supplier
                              > >>> (see ISO 15288 for interesting lifecycles)
                              > >>>
                              > >>>
                              > >>> * Commitments, duties attributed to either consumer or producer.
                              > >>> such as Delivery of Goods and Payments (reciprocity)
                              > >>> (see REA for examples)
                              > >>>
                              > >>> Above is presented from a business viewpoint (i.e. abstract)
                              > >>>
                              > >>> /anders w. tell
                              > >>> Senior ESA Architect
                              > >>> Standard strategist.
                              > >>>
                              > >>>
                              > >
                              > >
                              > >
                              >


                            • ramesh_nethi
                              Michael, Sorry, I may have replied at a wrong point in the thread. Earlier, Ashraf was talking about the choices in implementing business service – the
                              Message 14 of 15 , Apr 6, 2010
                                Michael,

                                Sorry, I may have replied at a wrong point in the thread. Earlier, Ashraf was talking about the choices in implementing business service – the choice between a business service returning 100 attributes and a business service returning consumer selected attributes. My understanding is that the latter approach is what REST advocates too. If you model that business service as a REST endpoint and the 100 attributes are that of a resource within that endpoint then returning a subset of attributes based on consumer's request is similar to returning a representation (or view or slice) of the same resource.

                                Regards
                                Ramesh


                                --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
                                >
                                > Ramesh, I do not see how this directly relates to REST principles. However, I'd like to notice that "choice of the implementer to do it in an intermediary or in the real service itself" does not appear as such to the consumer.
                                >
                                > If filtering is assigned (according to the Service Contract) to the service implementer (provider), then the consumer should not care how it is done; it always appears as in the service. The same is true about the reversal decision - consumer uses any means for the filtering and the service does not care about this subject - it is done inthe consumer.
                                >
                                > This comment relates to our discussion about 2 years old where we concluded that any intermediary (e.g., ESB) should be totally transparent for the consumer-service interaction, i.e. totally invisible to the opposite party. If the filter/ESB appears 'in clear' in between the consumer and the service and shields the service from the consumer, the latter should set the contract (Service Contract) with this ilter/ESB entity instead of the service because in this case the consumer does not know and does not need to know which actual service/provider would be used/chosen by the filter/ESB (intermediary).
                                >
                                > - Michael
                                >
                                >
                                >
                                > ________________________________
                                > From: ramesh_nethi <rn.lists@...>
                                > To: service-orientated-architecture@yahoogroups.com
                                > Sent: Mon, April 5, 2010 1:13:35 PM
                                > Subject: [service-orientated-architecture] Re: Services and Operations - Take 2
                                >
                                >
                                > Filtering in the service will also be along the lines of REST principles (i.e., let the Client negotiate and obtain a specified view of a given resource). Once this is done as a service contract, it is matter of choice of the implementer to do it in an intermediary or in the real service itself.
                                >
                                > Regards
                                > Ramesh
                                >
                                > --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3poulin@ .> wrote:
                                > >
                                > > Besides extra data moved between the service and an optional mediation layer, there are also security considerations. One of the sins of the use of a mediation layer for 'filtering' is the violation of the security golden rule - if data is not needed it may not leave its secured store. This means that the data may not leave either the service side or even the database (I wrote an article - Entitlement to Data - about this in 2006 and my method was taken by BEA for their security solution)
                                > >
                                > > If you delegate 'filtering' to the intermediary, you are making the intermediary the mandatory part of your SO solution. I am against such constraint.
                                > >
                                > > A business service should not worry <<worry about the specific mode of consumption in terms of the number of attributes>> , this is the worry of an Entitlement Service. Also, a business service may offer a feature of filtering-on- demand (<<the filter is done based on the consumer requests>>)
                                > >
                                > > - Michael
                                > >
                                > >
                                > >
                                > > ____________ _________ _________ __
                                > > From: Steve Jones <jones.steveg@ ...>
                                > > To: service-orientated- architecture@ yahoogroups. com
                                > > Sent: Mon, March 29, 2010 5:06:41 AM
                                > > Subject: Re: [service-orientated -architecture] Services and Operations - Take 2
                                > >
                                > >
                                > > I'm not sure it is silly to ship 100 attributes out to the mediation layer from a service. Now at the mediation layer (execution context type of thing) these could be stripped because the consumer doesn't require them but I'm not sure why a service should worry about the specific mode of consumption in terms of the number of attributes. If the filter is done based on the consumer requests and the filter is the responsibility of the consumer then they can take on more attributes without requiring a modification to the service.
                                > >
                                > > Steve
                                > >
                                > >
                                > >
                                > > On 28 March 2010 14:34, Michael Poulin <m3poulin@yahoo. com> wrote:
                                > >
                                > > >
                                > > >
                                > > >
                                > > >
                                > > >
                                > > >
                                > > >
                                > > >
                                > > >
                                > > >
                                > > >
                                > > >
                                > > >
                                > > >
                                > > > >
                                > > >
                                > > >>
                                > > >
                                > > >>
                                > > >
                                > > >I would disagree that filtering in the service restricts 'reusability' or a use by multiple clients (which is not the same thing to me) in any way. The filtering is the objective client's characteristic related to Entitlement. Each client must have its own View on the same data (single source of truth); it is a silly thing to move all 100 attributes to the one who needs only 3 out of them, IMO. Filtering in the service based on client entitlement or approved interests only adds flexibility to the service, and, thus, increases is client audience.
                                > > >
                                > > >
                                > > >But all this does not relate to the original question - what was an interaction with the service in the Anders' interpretation.
                                > > >
                                > > >
                                > > >- Michael
                                > > >
                                > > >
                                > > >
                                > > ____________ _________ _________ __
                                > > From: Ashraf Galal <ashrafwg@gmail. com>
                                > > >
                                > > >To: service-orientated- architecture@ yahoogroups. com
                                > > >Sent: Wed, March 24, 2010 11:48:32 AM
                                > > >
                                > > >Subject: Re: [service-orientated -architecture] Services and Operations - Take 2
                                > > >
                                > > >
                                > > > >
                                > > >
                                > > >
                                > > >>
                                > > >
                                > > >Usually, when designing a business service, we have to maximize
                                > > >>re-usability by designing its operations in a coarse-grained fashion.
                                > > >>For example, when retrieving customer data, almost more than 100
                                > > >>attributes, for example, are returned by the service, when then can be
                                > > >>filtered by the client side.
                                > > >>The alternative would have been to perform filtering within the service,
                                > > >>which would have restricted re-usability.
                                > > >> I think this is what he meant by his question.
                                > > >>All the best
                                > > >
                                > > >>Ashraf Galal
                                > > >
                                > > >>Michael Poulin wrote:
                                > > >>>
                                > > >>> Anders, can you explain <</each operation corresponds to one discrete
                                > > >>> consumer-provider interaction/ >>? Is it meant one type of interaction?
                                > > >>> How an 'interaction' is defined in this context? If I sent 2 different
                                > > >>> messages to the same operation, it it a case of 2 interactions because
                                > > >>> I communicated two times or because I communicated with two different
                                > > >>> messages?
                                > > >>>
                                > > >>> - Michael
                                > > >>>
                                > > >>>
                                > > >>> ------------ --------- --------- --------- --------- --------- -
                                > > >>> *From:* Anders Tell <anderst@toolsmiths . se>
                                > > >>> *To:* service-orientated- architecture@ yahoogroups. com
                                > > >>> *Sent:* Fri, March 19, 2010 3:29:56 PM
                                > > >>> *Subject:* Re: [service-orientated -architecture] Services and
                                > > >>> Operations - Take 2
                                > > >>>
                                > > >>>
                                > > >>>
                                > > >>>
                                > > >>>> /By contrast, the scope of functionality provided by an operation is
                                > > >>>> determined by consumer-provider interactions - each operation
                                > > >>>> corresponds to one discrete consumer-provider interaction/
                                > > >>>>
                                > > >>>
                                > > >>>
                                > > >>> Andrew, this is an interesting issue, how to bundle communicative acts
                                > > >>> as services (and operations).
                                > > >>>
                                > > >>> There exists three powerful aspects that can be used in/guiding such
                                > > >>> partitioning exercise
                                > > >>>
                                > > >>> * Conversations
                                > > >>>
                                > > >>> * Lifecycle(s) of entites that are of concerns to consumer and supplier
                                > > >>> (see ISO 15288 for interesting lifecycles)
                                > > >>>
                                > > >>>
                                > > >>> * Commitments, duties attributed to either consumer or producer.
                                > > >>> such as Delivery of Goods and Payments (reciprocity)
                                > > >>> (see REA for examples)
                                > > >>>
                                > > >>> Above is presented from a business viewpoint (i.e. abstract)
                                > > >>>
                                > > >>> /anders w. tell
                                > > >>> Senior ESA Architect
                                > > >>> Standard strategist.
                                > > >>>
                                > > >>>
                                > > >
                                > > >
                                > > >
                                > >
                                >
                              • Michael Poulin
                                I still think that the key here is
                                Message 15 of 15 , Apr 6, 2010

                                  I still think that the key here is <<a subset of attributes based on consumer's request>>, not REST or WS. One of possible solutions here is not only to define the data structure to be returned but, instead, to point to the XML Schema the response message should adhere to.

                                  - MIchael




                                  From: ramesh_nethi <rn.lists@...>
                                  To: service-orientated-architecture@yahoogroups.com
                                  Sent: Tue, April 6, 2010 10:27:25 AM
                                  Subject: [service-orientated-architecture] Re: Services and Operations - Take 2

                                   

                                  Michael,

                                  Sorry, I may have replied at a wrong point in the thread. Earlier, Ashraf was talking about the choices in implementing business service – the choice between a business service returning 100 attributes and a business service returning consumer selected attributes. My understanding is that the latter approach is what REST advocates too. If you model that business service as a REST endpoint and the 100 attributes are that of a resource within that endpoint then returning a subset of attributes based on consumer's request is similar to returning a representation (or view or slice) of the same resource.

                                  Regards
                                  Ramesh

                                  --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3poulin@.. .> wrote:
                                  >
                                  > Ramesh, I do not see how this directly relates to REST principles. However, I'd like to notice that "choice of the implementer to do it in an intermediary or in the real service itself" does not appear as such to the consumer.
                                  >
                                  > If filtering is assigned (according to the Service Contract) to the service implementer (provider), then the consumer should not care how it is done; it always appears as in the service. The same is true about the reversal decision - consumer uses any means for the filtering and the service does not care about this subject - it is done inthe consumer.
                                  >
                                  > This comment relates to our discussion about 2 years old where we concluded that any intermediary (e.g., ESB) should be totally transparent for the consumer-service interaction, i.e. totally invisible to the opposite party. If the filter/ESB appears 'in clear' in between the consumer and the service and shields the service from the consumer, the latter should set the contract (Service Contract) with this ilter/ESB entity instead of the service because in this case the consumer does not know and does not need to know which actual service/provider would be used/chosen by the filter/ESB (intermediary) .
                                  >
                                  > - Michael
                                  >
                                  >
                                  >
                                  > ____________ _________ _________ __
                                  > From: ramesh_nethi <rn.lists@.. .>
                                  > To: service-orientated- architecture@ yahoogroups. com
                                  > Sent: Mon, April 5, 2010 1:13:35 PM
                                  > Subject: [service-orientated -architecture] Re: Services and Operations - Take 2
                                  >
                                  >
                                  > Filtering in the service will also be along the lines of REST principles (i.e., let the Client negotiate and obtain a specified view of a given resource). Once this is done as a service contract, it is matter of choice of the implementer to do it in an intermediary or in the real service itself.
                                  >
                                  > Regards
                                  > Ramesh
                                  >
                                  > --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3poulin@ .> wrote:
                                  > >
                                  > > Besides extra data moved between the service and an optional mediation layer, there are also security considerations. One of the sins of the use of a mediation layer for 'filtering' is the violation of the security golden rule - if data is not needed it may not leave its secured store. This means that the data may not leave either the service side or even the database (I wrote an article - Entitlement to Data - about this in 2006 and my method was taken by BEA for their security solution)
                                  > >
                                  > > If you delegate 'filtering' to the intermediary, you are making the intermediary the mandatory part of your SO solution. I am against such constraint.
                                  > >
                                  > > A business service should not worry <<worry about the specific mode of consumption in terms of the number of attributes>> , this is the worry of an Entitlement Service. Also, a business service may offer a feature of filtering-on- demand (<<the filter is done based on the consumer requests>>)
                                  > >
                                  > > - Michael
                                  > >
                                  > >
                                  > >
                                  > > ____________ _________ _________ __
                                  > > From: Steve Jones <jones.steveg@ ...>
                                  > > To: service-orientated- architecture@ yahoogroups. com
                                  > > Sent: Mon, March 29, 2010 5:06:41 AM
                                  > > Subject: Re: [service-orientated -architecture] Services and Operations - Take 2
                                  > >
                                  > >
                                  > > I'm not sure it is silly to ship 100 attributes out to the mediation layer from a service. Now at the mediation layer (execution context type of thing) these could be stripped because the consumer doesn't require them but I'm not sure why a service should worry about the specific mode of consumption in terms of the number of attributes. If the filter is done based on the consumer requests and the filter is the responsibility of the consumer then they can take on more attributes without requiring a modification to the service.
                                  > >
                                  > > Steve
                                  > >
                                  > >
                                  > >
                                  > > On 28 March 2010 14:34, Michael Poulin <m3poulin@yahoo. com> wrote:
                                  > >
                                  > > >
                                  > > >
                                  > > >
                                  > > >
                                  > > >
                                  > > >
                                  > > >
                                  > > >
                                  > > >
                                  > > >
                                  > > >
                                  > > >
                                  > > >
                                  > > >
                                  > > > >
                                  > > >
                                  > > >>
                                  > > >
                                  > > >>
                                  > > >
                                  > > >I would disagree that filtering in the service restricts 'reusability' or a use by multiple clients (which is not the same thing to me) in any way. The filtering is the objective client's characteristic related to Entitlement. Each client must have its own View on the same data (single source of truth); it is a silly thing to move all 100 attributes to the one who needs only 3 out of them, IMO. Filtering in the service based on client entitlement or approved interests only adds flexibility to the service, and, thus, increases is client audience.
                                  > > >
                                  > > >
                                  > > >But all this does not relate to the original question - what was an interaction with the service in the Anders' interpretation.
                                  > > >
                                  > > >
                                  > > >- Michael
                                  > > >
                                  > > >
                                  > > >
                                  > > ____________ _________ _________ __
                                  > > From: Ashraf Galal <ashrafwg@gmail. com>
                                  > > >
                                  > > >To: service-orientated- architecture@ yahoogroups. com
                                  > > >Sent: Wed, March 24, 2010 11:48:32 AM
                                  > > >
                                  > > >Subject: Re: [service-orientated -architecture] Services and Operations - Take 2
                                  > > >
                                  > > >
                                  > > > >
                                  > > >
                                  > > >
                                  > > >>
                                  > > >
                                  > > >Usually, when designing a business service, we have to maximize
                                  > > >>re-usability by designing its operations in a coarse-grained fashion.
                                  > > >>For example, when retrieving customer data, almost more than 100
                                  > > >>attributes, for example, are returned by the service, when then can be
                                  > > >>filtered by the client side.
                                  > > >>The alternative would have been to perform filtering within the service,
                                  > > >>which would have restricted re-usability.
                                  > > >> I think this is what he meant by his question.
                                  > > >>All the best
                                  > > >
                                  > > >>Ashraf Galal
                                  > > >
                                  > > >>Michael Poulin wrote:
                                  > > >>>
                                  > > >>> Anders, can you explain <</each operation corresponds to one discrete
                                  > > >>> consumer-provider interaction/ >>? Is it meant one type of interaction?
                                  > > >>> How an 'interaction' is defined in this context? If I sent 2 different
                                  > > >>> messages to the same operation, it it a case of 2 interactions because
                                  > > >>> I communicated two times or because I communicated with two different
                                  > > >>> messages?
                                  > > >>>
                                  > > >>> - Michael
                                  > > >>>
                                  > > >>>
                                  > > >>> ------------ --------- --------- --------- --------- --------- -
                                  > > >>> *From:* Anders Tell <anderst@toolsmiths . se>
                                  > > >>> *To:* service-orientated- architecture@ yahoogroups. com
                                  > > >>> *Sent:* Fri, March 19, 2010 3:29:56 PM
                                  > > >>> *Subject:* Re: [service-orientated -architecture] Services and
                                  > > >>> Operations - Take 2
                                  > > >>>
                                  > > >>>
                                  > > >>>
                                  > > >>>
                                  > > >>>> /By contrast, the scope of functionality provided by an operation is
                                  > > >>>> determined by consumer-provider interactions - each operation
                                  > > >>>> corresponds to one discrete consumer-provider interaction/
                                  > > >>>>
                                  > > >>>
                                  > > >>>
                                  > > >>> Andrew, this is an interesting issue, how to bundle communicative acts
                                  > > >>> as services (and operations).
                                  > > >>>
                                  > > >>> There exists three powerful aspects that can be used in/guiding such
                                  > > >>> partitioning exercise
                                  > > >>>
                                  > > >>> * Conversations
                                  > > >>>
                                  > > >>> * Lifecycle(s) of entites that are of concerns to consumer and supplier
                                  > > >>> (see ISO 15288 for interesting lifecycles)
                                  > > >>>
                                  > > >>>
                                  > > >>> * Commitments, duties attributed to either consumer or producer.
                                  > > >>> such as Delivery of Goods and Payments (reciprocity)
                                  > > >>> (see REA for examples)
                                  > > >>>
                                  > > >>> Above is presented from a business viewpoint (i.e. abstract)
                                  > > >>>
                                  > > >>> /anders w. tell
                                  > > >>> Senior ESA Architect
                                  > > >>> Standard strategist.
                                  > > >>>
                                  > > >>>
                                  > > >
                                  > > >
                                  > > >
                                  > >
                                  >


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