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

RE: [service-orientated-architecture] Re: Multiple operation/interface per service

Expand Messages
  • Anil John
    Michael, ... deposit and withdraw ; ... while in both cases the ... introduce these generic ... domain specific names. ... language... Who on the business
    Message 1 of 11 , Oct 31 4:25 PM
      Michael,
       
      >For example,
      if we deal with a cash account, we better use operations "deposit" and "withdraw";
      >when we work
      with fund dealing, we use operations "buy" and "sell" while in both cases the
      >fundamental
      meanings of the operations are "in" and "out". I tried to introduce these generic
      >operation
      names but our business totally rejected it and required domain specific names.
      >This is
      understandable because SOA promises to speak business language...
       
      Who on the business side has visibility into that fine level of granularity?  The above would appear to be almost at the technical interface description level. I would think that you would be able to use the fundamental descriptions on the actual service interface but layer business/domain specific terminology on top of it.
       
      Regards,
       
      - Anil


      From: service-orientated-architecture@yahoogroups.com [mailto:service-orientated-architecture@yahoogroups.com] On Behalf Of Michael Poulin
      Sent: Tuesday, October 30, 2007 4:37 PM
      To: service-orientated-architecture@yahoogroups.com
      Subject: Re: [service-orientated-architecture] Re: Multiple operation/interface per service

      Multiple interfaces originate in two "things": different communication needs and different business execution context.

      By the former, I mean that the same service may deal with different sizes of transferred data, which may lead to a need for different protocols, end-points and interface implementation technique. This does not necessary means that the interface has to have different methods depending on the communication means but more likely different type of messages.

      By the latter, I mean that different business execution contexts may requite different business specific naming conventions. For example, if we deal with a cash account, we better use operations "deposit" and "withdraw"; when we work with fund dealing, we use operations "buy" and "sell" while in both cases the fundamental meanings of the operations are "in" and "out". I tried to introduce these generic operation names but our business totally rejected it and required domain specific names. This is understandable because SOA promises to speak business language...

      Additional source for multiple interfaces may come from security: some experts believe that if a user may no use an operation, it may not be shown to the user (instead of applying access controls on publicly visible interfaces).

      Versioning is totally out of this league to me because I do not accept an idea of separate versioning interfaces and services; for a consumer the service must have only one version covering logical/physical interface parts and service body/implementation all together.

      - Michael


      ----- Original Message ----
      From: Rob Eamon <reamon@...>
      To: service-orientated-architecture@yahoogroups.com
      Sent: Tuesday, October 30, 2007 3:36:23 PM
      Subject: [service-orientated-architecture] Re: Multiple operation/interface per service

      --- In service-orientated- architecture@ yahoogroups. com, "Steve Jones"
      <jones.steveg@ ...> wrote:
      >
      > ...The key is to
      > link them to differing business contexts and not allow them to
      > proliferate one for each client.
      > by 3) I mean when people ask for a new version for their project
      > and its delivered. These are the wrong ones, they aren't created
      > for a general business context they are created for a specific
      > point solution and represent a project specific change. These
      > create major issues of complexity, management and cost.

      This is indeed my concern. It would seem to be a symptom of doing
      things the same old way but now with services.

      IMO, this is where many service oriented efforts will go awry, much
      in the same fashion that EAI fell into disfavor. EAI was an approach-
      not-a-technology too, but many people associated it with specific
      technologies and ended up doing point-to-point solutions in a new-
      fangled way--and then were surprised when the system exhibited
      inflexibility (and blamed the tools). "But I'm using pub/sub so the
      solution is completely decoupled." Not so, Skippy. :-)

      -Rob



      __________________________________________________
      Do You Yahoo!?
      Tired of spam? Yahoo! Mail has the best spam protection around
      http://mail.yahoo.com
    • Michael Poulin
      In two financial institutions (1 League), business has/had special groups that communicate with IT and use business/IT terminology. The confusion always came
      Message 2 of 11 , Nov 1, 2007
        In two financial institutions (1 League), business has/had special groups that communicate with IT and use business/IT terminology. The confusion always came when IT created its own vocabulary and term meanings, so one of the goals was to start using business terminology , especially in dealing with business services (in IT).

        Moreover, since our UI is business function oriented, it is much easier for business and system analysts in IT  to use the same terminology in the UI and UI supporting business services than having a "map in the mind".

        However, my original question was about reusabilty and I still wait for somebody's response in this direction.

        - Michael

        ----- Original Message ----
        From: Anil John <aniltj@...>
        To: service-orientated-architecture@yahoogroups.com
        Sent: Wednesday, October 31, 2007 11:25:26 PM
        Subject: RE: [service-orientated-architecture] Re: Multiple operation/interface per service

        Michael,
         
        >For example, if we deal with a cash account, we better use operations "deposit" and "withdraw";
        >when we work with fund dealing, we use operations "buy" and "sell" while in both cases the
        >fundamental meanings of the operations are "in" and "out". I tried to introduce these generic
        >operation names but our business totally rejected it and required domain specific names.
        >This is understandable because SOA promises to speak business language...
         
        Who on the business side has visibility into that fine level of granularity?  The above would appear to be almost at the technical interface description level. I would think that you would be able to use the fundamental descriptions on the actual service interface but layer business/domain specific terminology on top of it.
         
        Regards,
         
        - Anil


        From: service-orientated- architecture@ yahoogroups. com [mailto:service- orientated- architecture@ yahoogroups. com] On Behalf Of Michael Poulin
        Sent: Tuesday, October 30, 2007 4:37 PM
        To: service-orientated- architecture@ yahoogroups. com
        Subject: Re: [service-orientated -architecture] Re: Multiple operation/interface per service

        Multiple interfaces originate in two "things": different communication needs and different business execution context.

        By the former, I mean that the same service may deal with different sizes of transferred data, which may lead to a need for different protocols, end-points and interface implementation technique. This does not necessary means that the interface has to have different methods depending on the communication means but more likely different type of messages.

        By the latter, I mean that different business execution contexts may requite different business specific naming conventions. For example, if we deal with a cash account, we better use operations "deposit" and "withdraw"; when we work with fund dealing, we use operations "buy" and "sell" while in both cases the fundamental meanings of the operations are "in" and "out". I tried to introduce these generic operation names but our business totally rejected it and required domain specific names. This is understandable because SOA promises to speak business language...

        Additional source for multiple interfaces may come from security: some experts believe that if a user may no use an operation, it may not be shown to the user (instead of applying access controls on publicly visible interfaces).

        Versioning is totally out of this league to me because I do not accept an idea of separate versioning interfaces and services; for a consumer the service must have only one version covering logical/physical interface parts and service body/implementation all together.

        - Michael


        ----- Original Message ----
        From: Rob Eamon <reamon@cableone. net>
        To: service-orientated- architecture@ yahoogroups. com
        Sent: Tuesday, October 30, 2007 3:36:23 PM
        Subject: [service-orientated -architecture] Re: Multiple operation/interface per service

        --- In service-orientated- architecture@ yahoogroups. com, "Steve Jones"
        <jones.steveg@ ...> wrote:
        >
        > ...The key is to
        > link them to differing business contexts and not allow them to
        > proliferate one for each client.
        > by 3) I mean when people ask for a new version for their project
        > and its delivered. These are the wrong ones, they aren't created
        > for a general business context they are created for a specific
        > point solution and represent a project specific change. These
        > create major issues of complexity, management and cost.

        This is indeed my concern. It would seem to be a symptom of doing
        things the same old way but now with services.

        IMO, this is where many service oriented efforts will go awry, much
        in the same fashion that EAI fell into disfavor. EAI was an approach-
        not-a-technology too, but many people associated it with specific
        technologies and ended up doing point-to-point solutions in a new-
        fangled way--and then were surprised when the system exhibited
        inflexibility (and blamed the tools). "But I'm using pub/sub so the
        solution is completely decoupled." Not so, Skippy. :-)

        -Rob



        ____________ _________ _________ _________ _________ __
        Do You Yahoo!?
        Tired of spam? Yahoo! Mail has the best spam protection around
        http://mail. yahoo.com


        __________________________________________________
        Do You Yahoo!?
        Tired of spam? Yahoo! Mail has the best spam protection around
        http://mail.yahoo.com
      • Steve Jones
        I m with you on the language point Michael, its why I used Virtual Services in the book to designate those services which don t in themselves have function
        Message 3 of 11 , Nov 2, 2007
          I'm with you on the language point Michael,  its why I used "Virtual Services" in the book to designate those services which don't in themselves have function but which are used to offer access to underlying capabilities.  If you are looking at areas where there are different languages that would enable reuse (or single use) this is a good reason to use Virtual services (things that in effect only exist as a result of mediation and have no direct business logic themselves) as it enables access of common underlying functions from several business areas but using the language that is specific for that area.

          I've seen the same things around stuff like Stock Control where its just putting boxes on shelves but in the warehouse they are "units" and in the back of store they are "products".

          Steve


          On 01/11/2007, Michael Poulin <m3poulin@...> wrote:

          In two financial institutions (1 League), business has/had special groups that communicate with IT and use business/IT terminology. The confusion always came when IT created its own vocabulary and term meanings, so one of the goals was to start using business terminology , especially in dealing with business services (in IT).

          Moreover, since our UI is business function oriented, it is much easier for business and system analysts in IT  to use the same terminology in the UI and UI supporting business services than having a "map in the mind".

          However, my original question was about reusabilty and I still wait for somebody's response in this direction.

          - Michael

          ----- Original Message ----
          From: Anil John <aniltj@...>
          To: service-orientated-architecture@yahoogroups.com
          Sent: Wednesday, October 31, 2007 11:25:26 PM
          Subject: RE: [service-orientated-architecture] Re: Multiple operation/interface per service

          Michael,
           
          >For example, if we deal with a cash account, we better use operations "deposit" and "withdraw";
          >when we work with fund dealing, we use operations "buy" and "sell" while in both cases the
          >fundamental meanings of the operations are "in" and "out". I tried to introduce these generic
          >operation names but our business totally rejected it and required domain specific names.
          >This is understandable because SOA promises to speak business language...
           
          Who on the business side has visibility into that fine level of granularity?  The above would appear to be almost at the technical interface description level. I would think that you would be able to use the fundamental descriptions on the actual service interface but layer business/domain specific terminology on top of it.
           
          Regards,
           
          - Anil


          From: service-orientated- architecture@ yahoogroups. com [mailto: service- orientated- architecture@ yahoogroups. com] On Behalf Of Michael Poulin
          Sent: Tuesday, October 30, 2007 4:37 PM
          To: service-orientated- architecture@ yahoogroups. com
          Subject: Re: [service-orientated -architecture] Re: Multiple operation/interface per service

          Multiple interfaces originate in two "things": different communication needs and different business execution context.

          By the former, I mean that the same service may deal with different sizes of transferred data, which may lead to a need for different protocols, end-points and interface implementation technique. This does not necessary means that the interface has to have different methods depending on the communication means but more likely different type of messages.

          By the latter, I mean that different business execution contexts may requite different business specific naming conventions. For example, if we deal with a cash account, we better use operations "deposit" and "withdraw"; when we work with fund dealing, we use operations "buy" and "sell" while in both cases the fundamental meanings of the operations are "in" and "out". I tried to introduce these generic operation names but our business totally rejected it and required domain specific names. This is understandable because SOA promises to speak business language...

          Additional source for multiple interfaces may come from security: some experts believe that if a user may no use an operation, it may not be shown to the user (instead of applying access controls on publicly visible interfaces).

          Versioning is totally out of this league to me because I do not accept an idea of separate versioning interfaces and services; for a consumer the service must have only one version covering logical/physical interface parts and service body/implementation all together.

          - Michael


          ----- Original Message ----
          From: Rob Eamon <reamon@cableone . net>
          To: service-orientated- architecture@ yahoogroups. com
          Sent: Tuesday, October 30, 2007 3:36:23 PM
          Subject: [service-orientated -architecture] Re: Multiple operation/interface per service

          --- In service-orientated- architecture@ yahoogroups. com, "Steve Jones"
          <jones.steveg@ ...> wrote:
          >
          > ...The key is to
          > link them to differing business contexts and not allow them to
          > proliferate one for each client.
          > by 3) I mean when people ask for a new version for their project
          > and its delivered. These are the wrong ones, they aren't created
          > for a general business context they are created for a specific
          > point solution and represent a project specific change. These
          > create major issues of complexity, management and cost.

          This is indeed my concern. It would seem to be a symptom of doing
          things the same old way but now with services.

          IMO, this is where many service oriented efforts will go awry, much
          in the same fashion that EAI fell into disfavor. EAI was an approach-
          not-a-technology too, but many people associated it with specific
          technologies and ended up doing point-to-point solutions in a new-
          fangled way--and then were surprised when the system exhibited
          inflexibility (and blamed the tools). "But I'm using pub/sub so the
          solution is completely decoupled." Not so, Skippy. :-)

          -Rob



          ____________ _________ _________ _________ _________ __
          Do You Yahoo!?
          Tired of spam? Yahoo! Mail has the best spam protection around
          http://mail. yahoo.com


          __________________________________________________
          Do You Yahoo!?
          Tired of spam? Yahoo! Mail has the best spam protection around
          http://mail.yahoo.com


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