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

Re: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

Expand Messages
  • Michael Poulin
    Hi David, thank you for the opportunity to explain the fundamental thing about service-oriented architecture and related modelling. Service, which I refer,
    Message 1 of 29 , Apr 1, 2013
      Hi David,

      thank you for the opportunity to explain the fundamental thing about service-oriented architecture and related modelling.

      Service, which I refer, starts in your PD layer and is known as business functionality offered by the service. Service can have as many different interfaces, including UI, as needed for particular consumer audience. In SO Ecosystem, it is the business functionality that drives the UI, not other way around (as many suggest).

      There are only 3 the most important attributes of a service for its consumers: 1) offered business functionality or the business tasks its helps to resolve; 2) outcome or Read World Effect (for the requester and others who has access to the outcome); 3) service conditions that include provided policies, execution context where the service guarantees offered results, SLA per interfaces, and alike. Combination of all these three attributes should be sufficient for a consumer to make a decision whether to use this service (i.e. the service can meet consumer's needs) or not.

      There is not such thing as a service layer - everything what an enterprise does is a service of certain granularity. Martin Fowler was the one who publicly expressed his hate to services but it did not help him because business works in services and does not want to know about DDD or DOSOM. I came up with DOSOM to mitigate a problem caused by OO inheritance. Particularly, again, if I start with DDD/OO I can create a very good domain-oriented set of objects/entities. However, the majority of cases, I will not be able to split these objects into independent services because they are coupled via inheritance (and code reuse). That is, I will be able to have a 'layer of interfaces' (as many call "service layer" which has nothing to do with services)  that are coupled underneath, through implementation. This kills a half of SO Principles. This is reason why it is practically impossible to convert a legacy application into a set of independent services. Example is SAP - does not matter how many Web Services or REST they expose, inside it is monolith. This means, if I try to use one SAP "service" in a combination with other services of mine, I will never be sure that implementation of other SAP "services" will not hurt my combination via used SAP "service".

      I hope, Davir, that you have a picture. Say Hello to Martin; he is a great man and professional but we cannot make one solution that fits everything (unless it exists already - the humanity is alive because it utilise service orientation).

      - Michael



      From: David Tildesley <davotnz@...>
      To: service-orientated-architecture@yahoogroups.com
      Sent: Sunday, March 31, 2013 10:41 AM
      Subject: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

       
      Hi Michael,

      That's a lot of overloaded concepts for me to respond to. However I will do my best.

      I am not sure that we are talking about the same thing and so I will start at the beginning:

      An application layering:

      UI ---> PD <--- SI

      (ignoring persistence)

      When I talk about modelling the domain I am talking about the PD layer only. PD = "Problem Domain" i.e. the layer that Martin Fowler refers to as the "rich domain layer". Of course this layer knows nothing about what you refer to as "services". The type of services you refer to are logically in the "UI" layer and of course the PD should never have any dependencies on the UI layer, nor any dependencies on the SI layer (The system integration layer - getting and putting data to other systems - this data is injected via DI in to the PD).

      This is standard stuff - the same PD layer can be used with different UI's because of it's independence, provided it is modeled well. DDD is used to model the PD layer (hence the 'D' = domain). As you should know, DDD all about the business and largely about behaviour.

      If I understand you correctly, everything you refer to as "service" is logically in the UI layer (especially the so called "service layer"). The boundary you talk of is a service boundary - something the PD cares not a jot about. Yep you can do what you like in your UI/"service layer" , DDD has absolutely nothing to say about it (and why should it?), however it's the PD layer that "does the business" and the UI/Service layer is a disposable appendage to service some interaction style or other, "SOA" or otherwise by some consumer or set of consumers that may be humans or may be another system.

      I seriously doubt that your "few famous OO designers" would care less about what you do in your service layer. However if you simultaneously confused the layers then I am sure you could get them very hot under the collar.

      David.

      --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
      >
      > Hi David,
      >  I know this is not a trivial matter, so, let me explain.
      >
      > First, I do not care of automation. I use OO as a modelling instrument for now.
      > Second, there are two different things: 1) defining an entity and the scope of its behaviour , and 2) implementing this entity.
      >
      > When I use service-oriented approach, I focus on a) what is the entity; b) what it does and why; c) for whom or who is the consumer; d) where and when this entity _operates_. Whether anyone may ask this entity to do something (and how this may be asked) is a different matter (interfaces are driven by the business behaviour, not other way around). Finally, I define this entity as totally independent that has its personal owner.
      >
      > Described knowledge gives me the boundaries of the entity (where entity=service in my case). Having the behabiour/functionality, defined outcome, and boundaries I can define interfaces that the service needs or wants to expose to consumers. Also, I can define other providers/services that my service needs to engage to obtain an information needed for its own execution. So far, there is no OO modelling.
      >
      > When the 'boundary job' is done, I am happy to invite DDD to model an implementation of the service (see DOSOM, http://www.ebizq.net/blogs/service_oriented/2009/01/a_domain_service-oriented_modelling_or_how_soa_meets_with_ddd.php) but only within defined boundaries. That is, no object inheritance may cross the service boundaries other way than through public interfaces. This is the key to the service implementation. I know a few famous OO designers who hate this - the fact that SOA dares to take the scoping and functionality of services away from objects.
      >
      > SOA has to do this because it models all - business objects, business information meta-models, business events, business processes, business activities, business relationships and rules, business policies, and even business operations and organisation structures.
      >
      > If I start with objects/DDD, a risk of tight coupling among functional components through inheritance and encapsulation is extremely high. I developed DOSOM to mitigate this risk. I discussed this with Eric Evans back in 2009 and he agreed with my movement around DDD for SOA.
      >
      > - Michael
      >



    • David Tildesley
      Hi Michael, Doesn t sound plausible to me. If I hear you correctly, you would take the few dozen business objects that ordinarily have multiple relationships
      Message 2 of 29 , Apr 2, 2013
        Hi Michael,

        Doesn't sound plausible to me. If I hear you correctly, you would take the few dozen business objects that ordinarily have multiple relationships and scores of behaviour (most of based on relationships) on each object and emaciate into an autonomous "service" for each "entity" equivalent. Impossible. Why would you do that.

        To put it into perspective take a small fraction of a HR domain:

        Employment
        Position
        PositionAssignment
        SkilledOne
        Person
        Organisation
        OrganisationUnit
        PositionEstablishment
        Office
        Location


        These are but a small fraction of the number of business objects in the PD layer for a typical HR application. Each one has behaviour, and each one is going to be messaging other business objects. More importantly these objects are generally on reuable with the context of the domain.

        Surely I am misreading what you are saying or you are not expressing yourself particularly well. In which case you need to provide a detailed example.

        Regards,
        David.

        --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
        >
        > Hi David,
        >
        > thank you for the opportunity to explain the fundamental thing about service-oriented architecture and related modelling.
        >
        > Service, which I refer, starts in your PD layer and is known as business functionality offered by the service. Service can have as many different interfaces, including UI, as needed for particular consumer audience. In SO Ecosystem, it is the business functionality that drives the UI, not other way around (as many suggest).
        >
        > There are only 3 the most important attributes of a service for its consumers: 1) offered business functionality or the business tasks its helps to resolve; 2) outcome or Read World Effect (for the requester and others who has access to the outcome); 3) service conditions that include provided policies, execution context where the service guarantees offered results, SLA per interfaces, and alike. Combination of all these three attributes should be sufficient for a consumer to make a decision whether to use this service (i.e. the service can meet consumer's needs) or not.
        >
        > There is not such thing as a service layer - everything what an enterprise does is a service of certain granularity. Martin Fowler was the one who publicly expressed his hate to services but it did not help him because business works in services and does not want to know about DDD or DOSOM. I came up with DOSOM to mitigate a problem caused by OO inheritance. Particularly, again, if I start with DDD/OO I can create a very good domain-oriented set of objects/entities. However, the majority of cases, I will not be able to split these objects into independent services because they are coupled via inheritance (and code reuse). That is, I will be able to have a 'layer of interfaces' (as many call "service layer" which has nothing to do with services)  that are coupled underneath, through implementation. This kills a half of SO Principles. This is reason why it is practically impossible to convert a legacy application into a set of independent services.
        > Example is SAP - does not matter how many Web Services or REST they expose, inside it is monolith. This means, if I try to use one SAP "service" in a combination with other services of mine, I will never be sure that implementation of other SAP "services" will not hurt my combination via used SAP "service".
        >
        > I hope, Davir, that you have a picture. Say Hello to Martin; he is a great man and professional but we cannot make one solution that fits everything (unless it exists already - the humanity is alive because it utilise service orientation).
        >
        > - Michael
        >
        >
      • Steve Jones
        As with an HR department its the service that does the orchestration of the various objects, the objects contain their rules of validity (as per good OO
        Message 3 of 29 , Apr 3, 2013
          As with an HR department its the service that does the orchestration of the various objects, the objects contain their rules of validity (as per good OO practice) but I'm not sure I'd see something like OrganisationUnit messaging anything.  Its part of a structure as laid down by the Finance department and consumed by the HR department.

          Steve


          On 2 Apr 2013, at 12:54, "David Tildesley" <davotnz@...> wrote:

           

          Hi Michael,

          Doesn't sound plausible to me. If I hear you correctly, you would take the few dozen business objects that ordinarily have multiple relationships and scores of behaviour (most of based on relationships) on each object and emaciate into an autonomous "service" for each "entity" equivalent. Impossible. Why would you do that.

          To put it into perspective take a small fraction of a HR domain:

          Employment
          Position
          PositionAssignment
          SkilledOne
          Person
          Organisation
          OrganisationUnit
          PositionEstablishment
          Office
          Location

          These are but a small fraction of the number of business objects in the PD layer for a typical HR application. Each one has behaviour, and each one is going to be messaging other business objects. More importantly these objects are generally on reuable with the context of the domain.

          Surely I am misreading what you are saying or you are not expressing yourself particularly well. In which case you need to provide a detailed example.

          Regards,
          David.

          --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
          >
          > Hi David,
          >
          > thank you for the opportunity to explain the fundamental thing about service-oriented architecture and related modelling.
          >
          > Service, which I refer, starts in your PD layer and is known as business functionality offered by the service. Service can have as many different interfaces, including UI, as needed for particular consumer audience. In SO Ecosystem, it is the business functionality that drives the UI, not other way around (as many suggest).
          >
          > There are only 3 the most important attributes of a service for its consumers: 1) offered business functionality or the business tasks its helps to resolve; 2) outcome or Read World Effect (for the requester and others who has access to the outcome); 3) service conditions that include provided policies, execution context where the service guarantees offered results, SLA per interfaces, and alike. Combination of all these three attributes should be sufficient for a consumer to make a decision whether to use this service (i.e. the service can meet consumer's needs) or not.
          >
          > There is not such thing as a service layer - everything what an enterprise does is a service of certain granularity. Martin Fowler was the one who publicly expressed his hate to services but it did not help him because business works in services and does not want to know about DDD or DOSOM. I came up with DOSOM to mitigate a problem caused by OO inheritance. Particularly, again, if I start with DDD/OO I can create a very good domain-oriented set of objects/entities. However, the majority of cases, I will not be able to split these objects into independent services because they are coupled via inheritance (and code reuse). That is, I will be able to have a 'layer of interfaces' (as many call "service layer" which has nothing to do with services)  that are coupled underneath, through implementation. This kills a half of SO Principles. This is reason why it is practically impossible to convert a legacy application into a set of independent services.
          > Example is SAP - does not matter how many Web Services or REST they expose, inside it is monolith. This means, if I try to use one SAP "service" in a combination with other services of mine, I will never be sure that implementation of other SAP "services" will not hurt my combination via used SAP "service".
          >
          > I hope, Davir, that you have a picture. Say Hello to Martin; he is a great man and professional but we cannot make one solution that fits everything (unless it exists already - the humanity is alive because it utilise service orientation).
          >
          > - Michael
          >
          >

        • Michael Poulin
          Hi David, SO approach is simply different - it deals with functions first and with entities (business data) second. For example, a company has a payment
          Message 4 of 29 , Apr 3, 2013
            Hi David,

            SO approach is simply different - it deals with functions first and with entities (business data) second. For example, a company has a payment function. It's realised via a Payment Service. The latter has a few sub-functions that may appear as _independent_ services while the Payment Service becomes just an orchestrator. These services are, e.g., Payment Verification, Fund Verification, Payee Verification, Local Compliance Verification, Payment Settlement, and Record Keeping.

            Instead of having all these operations as an interface operations in the Payment Service, I have only one or two operations there.

            Payment Verification is about payment status (regardless if it is made by Person, Organisation, OrganisationUnit, Group, Office).
            Fund Verification is about verification of payee's resources (regardless if this payee is Person, Organisation, OrganisationUnit, Group, Office).
            Payee Verification controls that the payment is made by legitimate actor (regardless if it is Person, Organisation, OrganisationUnit, Group, Office).
            Local Compliance Verification is about compliance of this payment with local law (regardless if it is Person, Organisation, OrganisationUnit, Group, Office who made the payment).
            Payment Settlement is about settlement of the payment
            Record Keeping is about recording the attributes of the payment in different record keeping stores including audit records.

            If tomorrow your business information model comes up with a notion of Benefit consisting of paying for the employee lunches, the Payment Service is ready to accommodate this new paying role with no modifications. It is possible because the Payment Service recognises only meta-data it defines. If you submit George Washington as a payee (defined in the service's meta definition of information), it will process the request.

            You are saying that objects behave. Good. But the business function is defined before any business entities come up, like "I have a job and the workers come later, by themselves". So, my task is to define the boundaries/scope of the job/task/function/service and give it to professionals to realise it, and professionals/objects can behave in any way they prefer but inside my pre-defined functionality.

            If I imagine a wild (usually Asian) market where everyone sells and buys things with no order, I will easily find a raw meat next to bread and chemistry next to milk, and they reuse the measures and plates/cans. Since people group based on their relationships, it will be very difficult to separate bread-sellers from meat-sellers because such neighboring is dangerous for the health of buyers and because some of the sellers do not have their own measures but have to pay to strangers if they use their measures. This is the problem DOSOM solves vs. DDD.

            - Michael



            From: David Tildesley <davotnz@...>
            To: service-orientated-architecture@yahoogroups.com
            Sent: Tuesday, April 2, 2013 8:54 PM
            Subject: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

             
            Hi Michael,

            Doesn't sound plausible to me. If I hear you correctly, you would take the few dozen business objects that ordinarily have multiple relationships and scores of behaviour (most of based on relationships) on each object and emaciate into an autonomous "service" for each "entity" equivalent. Impossible. Why would you do that.

            To put it into perspective take a small fraction of a HR domain:

            Employment
            Position
            PositionAssignment
            SkilledOne
            Person
            Organisation
            OrganisationUnit
            PositionEstablishment
            Office
            Location

            These are but a small fraction of the number of business objects in the PD layer for a typical HR application. Each one has behaviour, and each one is going to be messaging other business objects. More importantly these objects are generally on reuable with the context of the domain.

            Surely I am misreading what you are saying or you are not expressing yourself particularly well. In which case you need to provide a detailed example.

            Regards,
            David.

            --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
            >
            > Hi David,
            >
            > thank you for the opportunity to explain the fundamental thing about service-oriented architecture and related modelling.
            >
            > Service, which I refer, starts in your PD layer and is known as business functionality offered by the service. Service can have as many different interfaces, including UI, as needed for particular consumer audience. In SO Ecosystem, it is the business functionality that drives the UI, not other way around (as many suggest).
            >
            > There are only 3 the most important attributes of a service for its consumers: 1) offered business functionality or the business tasks its helps to resolve; 2) outcome or Read World Effect (for the requester and others who has access to the outcome); 3) service conditions that include provided policies, execution context where the service guarantees offered results, SLA per interfaces, and alike. Combination of all these three attributes should be sufficient for a consumer to make a decision whether to use this service (i.e. the service can meet consumer's needs) or not.
            >
            > There is not such thing as a service layer - everything what an enterprise does is a service of certain granularity. Martin Fowler was the one who publicly expressed his hate to services but it did not help him because business works in services and does not want to know about DDD or DOSOM. I came up with DOSOM to mitigate a problem caused by OO inheritance. Particularly, again, if I start with DDD/OO I can create a very good domain-oriented set of objects/entities. However, the majority of cases, I will not be able to split these objects into independent services because they are coupled via inheritance (and code reuse). That is, I will be able to have a 'layer of interfaces' (as many call "service layer" which has nothing to do with services)  that are coupled underneath, through implementation. This kills a half of SO Principles. This is reason why it is practically impossible to convert a legacy application into a set of independent services.
            > Example is SAP - does not matter how many Web Services or REST they expose, inside it is monolith. This means, if I try to use one SAP "service" in a combination with other services of mine, I will never be sure that implementation of other SAP "services" will not hurt my combination via used SAP "service".
            >
            > I hope, Davir, that you have a picture. Say Hello to Martin; he is a great man and professional but we cannot make one solution that fits everything (unless it exists already - the humanity is alive because it utilise service orientation).
            >
            > - Michael
            >
            >



          • David Tildesley
            Hi Michael, I have no quarrel with the services you define (as a consumer would view them), however you reneged (again) on providing the implementation example
            Message 5 of 29 , Apr 4, 2013

              Hi Michael,

              I have no quarrel with the services you define (as a consumer would view them), however you reneged (again) on providing the implementation example I asked for.

              Essentially what you have been proposing (in your previous post) is to implement business logic in consumer interaction specific code (i.e. service layer) - the exact opposite of what Martin Fowler was talking about in the "rich domain" model and is an extreme example of the anemic domain model anti-pattern and the very thing that leads to procedural, hard to maintain code and shortened application life - you may as well write it in COBOL. Brittle. Very brittle. 

              For all our sakes, catch up with the world and understand that OO design in the last two decades very rarely uses class inheritance (because it can be brittle) and please stop knocking OO design for something that is now rare and when used, it is used judiciously. Inheritance doesn't bleed out into the UI layer (where the Service layer resides) - when it is used in the PD layer it is essentially implementation detail that is hidden from the consumer of the PD layer (i.e the UI layer where the service layer resides).

              As I stated in previous posts, a company can  achieve  implementing a service of exactly how you describe a service, and at the same time preserve the company's application/component domain layer as an enduring layer of value. 

              There is absolutely no need to butcher the domain layer to achieve SOA. To butcher the domain layer like you suggest may not be noticed by your consumers for a while (possibly a month or two) if the project manages to go live - until change inevitably happens (possibly within the SDLC of the project) and the brittleness leads to shortened application code life and in the worse case , non-delivery and loss of company value.


              David.


               
              Hi David,

              SO approach is simply different - it deals with functions first and with entities (business data) second. For example, a company has a payment function. It's realised via a Payment Service. The latter has a few sub-functions that may appear as _independent_ services while the Payment Service becomes just an orchestrator. These services are, e.g., Payment Verification, Fund Verification, Payee Verification, Local Compliance Verification, Payment Settlement, and Record Keeping.

              Instead of having all these operations as an interface operations in the Payment Service, I have only one or two operations there.

              Payment Verification is about payment status (regardless if it is made by Person, Organisation, OrganisationUnit, Group, Office).
              Fund Verification is about verification of payee's resources (regardless if this payee is Person, Organisation, OrganisationUnit, Group, Office).
              Payee Verification controls that the payment is made by legitimate actor (regardless if it is Person, Organisation, OrganisationUnit, Group, Office).
              Local Compliance Verification is about compliance of this payment with local law (regardless if it is Person, Organisation, OrganisationUnit, Group, Office who made the payment).
              Payment Settlement is about settlement of the payment
              Record Keeping is about recording the attributes of the payment in different record keeping stores including audit records.

              If tomorrow your business information model comes up with a notion of Benefit consisting of paying for the employee lunches, the Payment Service is ready to accommodate this new paying role with no modifications. It is possible because the Payment Service recognises only meta-data it defines. If you submit George Washington as a payee (defined in the service's meta definition of information), it will process the request.

              You are saying that objects behave. Good. But the business function is defined before any business entities come up, like "I have a job and the workers come later, by themselves". So, my task is to define the boundaries/scope of the job/task/function/service and give it to professionals to realise it, and professionals/objects can behave in any way they prefer but inside my pre-defined functionality.

              If I imagine a wild (usually Asian) market where everyone sells and buys things with no order, I will easily find a raw meat next to bread and chemistry next to milk, and they reuse the measures and plates/cans. Since people group based on their relationships, it will be very difficult to separate bread-sellers from meat-sellers because such neighboring is dangerous for the health of buyers and because some of the sellers do not have their own measures but have to pay to strangers if they use their measures. This is the problem DOSOM solves vs. DDD.

              - Michael







            • Michael Poulin
              David, if I disagree with Martin , it is OK and healthy if it makes sense. I am trying to explain this sense. Which text of mine you read as to implement
              Message 6 of 29 , Apr 6, 2013
                David, if I disagree with Martin , it is OK and healthy if it makes sense. I am trying to explain this sense.

                Which text of mine you read as "to implement business logic in consumer interaction specific code"? I never said so. Moreover, I explicitly pointed to the fact that consumer interaction specific code is the _secondary_ (if exists at all) to the business logic of the service. I said that this logic is defined at the service level - logical design level - and only implemented (not discovered) by objects. And service is not designed to handle any consumer specific code - it works against market and service composability/flexibility.

                Please, before calling my logic "Brittle", emember that services ARE NOT OBLIGED having consumer interaction code in sense of UI at all. Any consumer interacts with a service via its public interfaces; no object back -door.

                As of "procedural, hard to maintain code" - this admission only confirms that there are things in the business - business procedure - that objects are not the best modelling means for.

                Yes, "a company can  achieve  implementing a service... domain layer as an enduring layer of value" but not via placing new interface on a monolith application - Web Service interface does not make an application a service (because it does not enforces the application behave differently only because it is accessed via WS). But this is a different topic.

                If you dislike inheritance, let's take Spring and injections. Stupid EJB 3.0 and Spring allow objects to become self-persisted and linked with whatever messaging systems at the level of object. It is good for developers but not for architects who have to control access to resources and relationships between entities. If such self-contained object is moved into another execution environment where no messaging available or another messaging exist that the object is not prepared for, what it will do? I cannot use such object in the services because this creates dependency of the logical functionality from the mechanics of implementation, which is not acceptable in SO Ecosystem.

                It is the service who decides what data store or messaging to use, when, where and though which public interface. It is not a competence of the objects any more - we have created a higher layer of abstraction with services. This is what, I am afraid, you do not want to accept.

                Sorry, but I have not understood you last paragraph.

                - Michael



                From: David Tildesley <davotnz@...>
                To: "service-orientated-architecture@yahoogroups.com" <service-orientated-architecture@yahoogroups.com>
                Sent: Thursday, April 4, 2013 9:33 AM
                Subject: Re: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

                 

                Hi Michael,

                I have no quarrel with the services you define (as a consumer would view them), however you reneged (again) on providing the implementation example I asked for.

                Essentially what you have been proposing (in your previous post) is to implement business logic in consumer interaction specific code (i.e. service layer) - the exact opposite of what Martin Fowler was talking about in the "rich domain" model and is an extreme example of the anemic domain model anti-pattern and the very thing that leads to procedural, hard to maintain code and shortened application life - you may as well write it in COBOL. Brittle. Very brittle. 

                For all our sakes, catch up with the world and understand that OO design in the last two decades very rarely uses class inheritance (because it can be brittle) and please stop knocking OO design for something that is now rare and when used, it is used judiciously. Inheritance doesn't bleed out into the UI layer (where the Service layer resides) - when it is used in the PD layer it is essentially implementation detail that is hidden from the consumer of the PD layer (i.e the UI layer where the service layer resides).

                As I stated in previous posts, a company can  achieve  implementing a service of exactly how you describe a service, and at the same time preserve the company's application/component domain layer as an enduring layer of value. 

                There is absolutely no need to butcher the domain layer to achieve SOA. To butcher the domain layer like you suggest may not be noticed by your consumers for a while (possibly a month or two) if the project manages to go live - until change inevitably happens (possibly within the SDLC of the project) and the brittleness leads to shortened application code life and in the worse case , non-delivery and loss of company value.


                David.


                 
                Hi David,

                SO approach is simply different - it deals with functions first and with entities (business data) second. For example, a company has a payment function. It's realised via a Payment Service. The latter has a few sub-functions that may appear as _independent_ services while the Payment Service becomes just an orchestrator. These services are, e.g., Payment Verification, Fund Verification, Payee Verification, Local Compliance Verification, Payment Settlement, and Record Keeping.

                Instead of having all these operations as an interface operations in the Payment Service, I have only one or two operations there.

                Payment Verification is about payment status (regardless if it is made by Person, Organisation, OrganisationUnit, Group, Office).
                Fund Verification is about verification of payee's resources (regardless if this payee is Person, Organisation, OrganisationUnit, Group, Office).
                Payee Verification controls that the payment is made by legitimate actor (regardless if it is Person, Organisation, OrganisationUnit, Group, Office).
                Local Compliance Verification is about compliance of this payment with local law (regardless if it is Person, Organisation, OrganisationUnit, Group, Office who made the payment).
                Payment Settlement is about settlement of the payment
                Record Keeping is about recording the attributes of the payment in different record keeping stores including audit records.

                If tomorrow your business information model comes up with a notion of Benefit consisting of paying for the employee lunches, the Payment Service is ready to accommodate this new paying role with no modifications. It is possible because the Payment Service recognises only meta-data it defines. If you submit George Washington as a payee (defined in the service's meta definition of information), it will process the request.

                You are saying that objects behave. Good. But the business function is defined before any business entities come up, like "I have a job and the workers come later, by themselves". So, my task is to define the boundaries/scope of the job/task/function/service and give it to professionals to realise it, and professionals/objects can behave in any way they prefer but inside my pre-defined functionality.

                If I imagine a wild (usually Asian) market where everyone sells and buys things with no order, I will easily find a raw meat next to bread and chemistry next to milk, and they reuse the measures and plates/cans. Since people group based on their relationships, it will be very difficult to separate bread-sellers from meat-sellers because such neighboring is dangerous for the health of buyers and because some of the sellers do not have their own measures but have to pay to strangers if they use their measures. This is the problem DOSOM solves vs. DDD.

                - Michael









              • David Tildesley
                Hi Michael, ... sense. I am trying to explain this sense. ... But what you are saying makes no sense. Martin makes perfect sense when he describes his
                Message 7 of 29 , Apr 6, 2013
                  Hi Michael,


                  --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
                  >
                  > David, if I disagree with Martin , it is OK and healthy if it makes sense. I am trying to explain this sense.

                  But what you are saying makes no sense. Martin makes perfect sense when he describes his enterprise patterns. You are saying he is wrong without providing a convincing argument as to why he is wrong. I believe it was Martin who first documented the IoC and DI patterns that Spring and other frameworks used today and tens of thousands of successful applications are delivered using. DI is used when your application needs to interact with another system (maybe via an enterprise service or maybe not depending on the situation). It keeps the domain layer free of dependency on these integrations with other systems.  Yes, data persistence has been relegated to the background with the more than capable frameworks (Hibernate, JPA, JDO etc.).

                  I wouldn't disagree with you about the "lipstick on a pig" approach that some significant vendors have taken to eek out the revenue stream on their "monolithic" applications by bolting on web-services.  Few, if any,  of these monoliths have been sensibly designed using good OO design approaches and many  still show their cobol heritage and many still have underlying cobol code. At least one large vendor has recognised that this approach needs to change and have started on that path by rebuilding their monolith(s) into functionally cohesive  blocks. Each of those blocks of course would take an OO approach to implementing the domain layer.

                  Finally, this latest explanation in your post is just like the previous - you are advocating an "entity" based service implementation all the way down to the data store itself. Your services have functional names but yet apparently they deal with single entities. We look at the functional names and know full well that there would be multiple entities involved. And the very next service that comes along will need to use some of those entities and use the business logic which has now been locked away in a service specific implementation - what are you going to do? copy and paste the business logic from one to the other? or would you put 1000's of "if ... else .. if ... else ..."? Sorry, your implementation idea has so many flaws in it and flies in the face of years of experience and accumulated knowledge articulated by the likes of Martin.

                  I'm not sure what you didn't understand about my last paragraph - it was simply summing up my analysis of your implementation approach.

                  Let me restate my position: Service implementation does not belong  in the rich domain layer of an application, nor should it replace it. Instead, service implementation in a separate layer  (just  like the UI layer which is logically in) consumes the UI independent API of the rich domain layer. The Service implementation does indeed offer an API to consumers, however the rich domain layer of the application should not and need not have any knowledge or dependency on that. Let me show this again:

                  (consumer) --> UI (service layer) ---> PD (rich domain) <--- SI (consumer of some other service) 

                  The arrows indicate direction of dependency (i.e the PD is independent of any other layer which allows it to be an enduring layer for the business). N.B. Not bothering to show the data persistance, however you should know the persistance behaviour is applied directly to the business objects via the persistence frameworks (no need for DAO pattern anymore in the majority of applications).

                  Regards,
                  David.

                  > Which text of mine you read as "to implement business logic in consumer interaction specific code"? I never said so. Moreover, I explicitly pointed to the fact that consumer interaction specific code is the _secondary_ (if exists at all) to the business logic of the service. I said that this logic is defined at the service level - logical design level - and only implemented (not discovered) by objects. And service is not designed to handle any consumer specific code - it works against market and service composability/flexibility.
                  >
                  > Please, before calling my logic "Brittle", emember that services ARE NOT OBLIGED having consumer interaction code in sense of UI at all. Any consumer interacts with a service via its public interfaces; no object back -door.
                  >
                  > As of "procedural, hard to maintain code" - this admission only confirms that there are things in the business - business procedure - that objects are not the best modelling means for.
                  >
                  > Yes, "a company can  achieve  implementing a service... domain layer as an enduring layer of value" but not via placing new interface on a monolith application - Web Service interface does not make an application a service (because it does not enforces the application behave differently only because it is accessed via WS). But this is a different topic.
                  >
                  > If you dislike inheritance, let's take Spring and injections. Stupid EJB 3.0 and Spring allow objects to become self-persisted and linked with whatever messaging systems at the level of object. It is good for developers but not for architects who have to control access to resources and relationships between entities. If such self-contained object is moved into another execution environment where no messaging available or another messaging exist that the object is not prepared for, what it will do? I cannot use such object in the services because this creates dependency of the logical functionality from the mechanics of implementation, which is not acceptable in SO Ecosystem.
                  >
                  > It is the service who decides what data store or messaging to use, when, where and though which public interface. It is not a competence of the objects any more - we have created a higher layer of abstraction with services. This is what, I am afraid, you do not want to accept.
                  >
                  > Sorry, but I have not understood you last paragraph.
                  >
                  > - Michael
                  >

                • Michael Poulin
                  Hi David, what read all time in your comments is a pure IT viewpoint which I do not use anymore. This is why you do not understand me. See, you say DI is used
                  Message 8 of 29 , Apr 9, 2013
                    Hi David,

                    what read all time in your comments is a pure IT viewpoint which I do not use anymore. This is why you do not understand me. See, you say "DI is used when your application needs to interact with another system (maybe via an enterprise service or maybe not depending on the situation). " In SOA Ecosystem, it is not a task because no one application needs to interact with another system - there are no such entities as an application that may need anything. _All_ applications must be inside services as their implementation; they cannot need anything but it is a service's business functionality needs another business functionality and outcomes regardless if there are systems, platforms or applications in that service.

                    Spring and similar frameworks work in millions applications but this does not make them more or less suitable for services. Numbers are not arguments. If a service gets limitations in composability because Spring used for implementation coupled it with particular database (or another application/package that is not included into this service's code base) , the service will not use such a solutions and will either spend resources to verify that such things will not be done in the code ever or (instead of spending resources)  simply will not use Spring framework at all because it is too risky and expensive to make work right.

                    If a business functionality of a service needs to work with many business informational entities, SE Ecosystem reserves a special type of services called Data Access Services (DAS). All source data is obtained from the data sources and persisted in these data sources via DAS. These services know the business semantic models used by different business services (their clients) as well as all technicalities and schemas of physical data storage, and perform data transformation where needed. This is why business services never own the data or data sources; they own only business semantic meta-models thwy know how to work with. It is a service that makes sense of actual data, not IT's DB or a canonical data model.

                    Two last points:

                    1) "however the rich domain layer of the application should not and need not have any knowledge or dependency on that [interface API]" - 100% agree with this.

                    2) "Service implementation does not belong  in the rich domain layer of an application, nor should it replace it. Instead, service implementation in a separate layer  (just  like the UI layer which is logically in) consumes the UI independent API of the rich domain layer. " - 100% disagree with this. Service implementation IS the rich domain layer comprised one or several applications or components (this is the preference of implementation only and may not impact service functionality and the outcome). Service is not an abstraction when it is implemented. And this implementation - the rich domain - must be implemented in compliance with Principles of Service Orientation. [If an application realises a business function but is constructed not in line with PSO, it requires a re-design and re-implementation to become a service. This is not done, such application may not be used in SO Ecosystem but can serve as a data resource].

                    This is all, David. I have said all I wanted to say.

                    Thanks,
                    - Michael





                    From: David Tildesley <davotnz@...>
                    To: service-orientated-architecture@yahoogroups.com
                    Sent: Sunday, April 7, 2013 2:26 AM
                    Subject: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

                     
                    Hi Michael,


                    --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
                    >
                    > David, if I disagree with Martin , it is OK and healthy if it makes sense. I am trying to explain this sense.

                    But what you are saying makes no sense. Martin makes perfect sense when he describes his enterprise patterns. You are saying he is wrong without providing a convincing argument as to why he is wrong. I believe it was Martin who first documented the IoC and DI patterns that Spring and other frameworks used today and tens of thousands of successful applications are delivered using. DI is used when your application needs to interact with another system (maybe via an enterprise service or maybe not depending on the situation). It keeps the domain layer free of dependency on these integrations with other systems.  Yes, data persistence has been relegated to the background with the more than capable frameworks (Hibernate, JPA, JDO etc.).

                    I wouldn't disagree with you about the "lipstick on a pig" approach that some significant vendors have taken to eek out the revenue stream on their "monolithic" applications by bolting on web-services.  Few, if any,  of these monoliths have been sensibly designed using good OO design approaches and many  still show their cobol heritage and many still have underlying cobol code. At least one large vendor has recognised that this approach needs to change and have started on that path by rebuilding their monolith(s) into functionally cohesive  blocks. Each of those blocks of course would take an OO approach to implementing the domain layer.

                    Finally, this latest explanation in your post is just like the previous - you are advocating an "entity" based service implementation all the way down to the data store itself. Your services have functional names but yet apparently they deal with single entities. We look at the functional names and know full well that there would be multiple entities involved. And the very next service that comes along will need to use some of those entities and use the business logic which has now been locked away in a service specific implementation - what are you going to do? copy and paste the business logic from one to the other? or would you put 1000's of "if ... else .. if ... else ..."? Sorry, your implementation idea has so many flaws in it and flies in the face of years of experience and accumulated knowledge articulated by the likes of Martin.

                    I'm not sure what you didn't understand about my last paragraph - it was simply summing up my analysis of your implementation approach.

                    Let me restate my position: Service implementation does not belong  in the rich domain layer of an application, nor should it replace it. Instead, service implementation in a separate layer  (just  like the UI layer which is logically in) consumes the UI independent API of the rich domain layer. The Service implementation does indeed offer an API to consumers, however the rich domain layer of the application should not and need not have any knowledge or dependency on that. Let me show this again:

                    (consumer) --> UI (service layer) ---> PD (rich domain) <--- SI (consumer of some other service) 

                    The arrows indicate direction of dependency (i.e the PD is independent of any other layer which allows it to be an enduring layer for the business). N.B. Not bothering to show the data persistance, however you should know the persistance behaviour is applied directly to the business objects via the persistence frameworks (no need for DAO pattern anymore in the majority of applications).

                    Regards,
                    David.

                    > Which text of mine you read as "to implement business logic in consumer interaction specific code"? I never said so. Moreover, I explicitly pointed to the fact that consumer interaction specific code is the _secondary_ (if exists at all) to the business logic of the service. I said that this logic is defined at the service level - logical design level - and only implemented (not discovered) by objects. And service is not designed to handle any consumer specific code - it works against market and service composability/flexibility.
                    >
                    > Please, before calling my logic "Brittle", emember that services ARE NOT OBLIGED having consumer interaction code in sense of UI at all. Any consumer interacts with a service via its public interfaces; no object back -door.
                    >
                    > As of "procedural, hard to maintain code" - this admission only confirms that there are things in the business - business procedure - that objects are not the best modelling means for.
                    >
                    > Yes, "a company can  achieve  implementing a service... domain layer as an enduring layer of value" but not via placing new interface on a monolith application - Web Service interface does not make an application a service (because it does not enforces the application behave differently only because it is accessed via WS). But this is a different topic.
                    >
                    > If you dislike inheritance, let's take Spring and injections. Stupid EJB 3.0 and Spring allow objects to become self-persisted and linked with whatever messaging systems at the level of object. It is good for developers but not for architects who have to control access to resources and relationships between entities. If such self-contained object is moved into another execution environment where no messaging available or another messaging exist that the object is not prepared for, what it will do? I cannot use such object in the services because this creates dependency of the logical functionality from the mechanics of implementation, which is not acceptable in SO Ecosystem.
                    >
                    > It is the service who decides what data store or messaging to use, when, where and though which public interface. It is not a competence of the objects any more - we have created a higher layer of abstraction with services. This is what, I am afraid, you do not want to accept.
                    >
                    > Sorry, but I have not understood you last paragraph.
                    >
                    > - Michael
                    >



                  • Ashraf Galal
                    I disagree with your point. We have to look to the enterprise as the system and IT as subsystems. We NEED tools for the management and change of enterprises.
                    Message 9 of 29 , Apr 10, 2013

                      I disagree with your point. 
                      We have to look to the enterprise as the system and IT as subsystems.

                      We NEED tools for the management and change of enterprises.

                      The systems approach: viewing the enterprise itself as the main enterprise system, with the information system as a subsystem.

                      The general idea is that we have to be able to grasp both the enterprise system and the information system in a thorough and comprehensive way to be able to manage change.
                      We are trying to cross the gap between business and IT, not to pass the dilmma to the business.

                      All the best

                      Ashraf Galal





                      On 4/9/2013 3:24 PM, Michael Poulin wrote:
                       
                      Hi David,

                      what read all time in your comments is a pure IT viewpoint which I do not use anymore. This is why you do not understand me. See, you say "DI is used when your application needs to interact with another system (maybe via an enterprise service or maybe not depending on the situation). " In SOA Ecosystem, it is not a task because no one application needs to interact with another system - there are no such entities as an application that may need anything. _All_ applications must be inside services as their implementation; they cannot need anything but it is a service's business functionality needs another business functionality and outcomes regardless if there are systems, platforms or applications in that service.

                      Spring and similar frameworks work in millions applications but this does not make them more or less suitable for services. Numbers are not arguments. If a service gets limitations in composability because Spring used for implementation coupled it with particular database (or another application/package that is not included into this service's code base) , the service will not use such a solutions and will either spend resources to verify that such things will not be done in the code ever or (instead of spending resources)  simply will not use Spring framework at all because it is too risky and expensive to make work right.

                      If a business functionality of a service needs to work with many business informational entities, SE Ecosystem reserves a special type of services called Data Access Services (DAS). All source data is obtained from the data sources and persisted in these data sources via DAS. These services know the business semantic models used by different business services (their clients) as well as all technicalities and schemas of physical data storage, and perform data transformation where needed. This is why business services never own the data or data sources; they own only business semantic meta-models thwy know how to work with. It is a service that makes sense of actual data, not IT's DB or a canonical data model.

                      Two last points:

                      1) "however the rich domain layer of the application should not and need not have any knowledge or dependency on that [interface API]" - 100% agree with this.

                      2) "Service implementation does not belong  in the rich domain layer of an application, nor should it replace it. Instead, service implementation in a separate layer  (just  like the UI layer which is logically in) consumes the UI independent API of the rich domain layer. " - 100% disagree with this. Service implementation IS the rich domain layer comprised one or several applications or components (this is the preference of implementation only and may not impact service functionality and the outcome). Service is not an abstraction when it is implemented. And this implementation - the rich domain - must be implemented in compliance with Principles of Service Orientation. [If an application realises a business function but is constructed not in line with PSO, it requires a re-design and re-implementation to become a service. This is not done, such application may not be used in SO Ecosystem but can serve as a data resource].

                      This is all, David. I have said all I wanted to say.

                      Thanks,
                      - Michael





                      From: David Tildesley <davotnz@...>
                      To: service-orientated-architecture@yahoogroups.com
                      Sent: Sunday, April 7, 2013 2:26 AM
                      Subject: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

                       
                      Hi Michael,


                      --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
                      >
                      > David, if I disagree with Martin , it is OK and healthy if it makes sense. I am trying to explain this sense.

                      But what you are saying makes no sense. Martin makes perfect sense when he describes his enterprise patterns. You are saying he is wrong without providing a convincing argument as to why he is wrong. I believe it was Martin who first documented the IoC and DI patterns that Spring and other frameworks used today and tens of thousands of successful applications are delivered using. DI is used when your application needs to interact with another system (maybe via an enterprise service or maybe not depending on the situation). It keeps the domain layer free of dependency on these integrations with other systems.  Yes, data persistence has been relegated to the background with the more than capable frameworks (Hibernate, JPA, JDO etc.).

                      I wouldn't disagree with you about the "lipstick on a pig" approach that some significant vendors have taken to eek out the revenue stream on their "monolithic" applications by bolting on web-services.  Few, if any,  of these monoliths have been sensibly designed using good OO design approaches and many  still show their cobol heritage and many still have underlying cobol code. At least one large vendor has recognised that this approach needs to change and have started on that path by rebuilding their monolith(s) into functionally cohesive  blocks. Each of those blocks of course would take an OO approach to implementing the domain layer.

                      Finally, this latest explanation in your post is just like the previous - you are advocating an "entity" based service implementation all the way down to the data store itself. Your services have functional names but yet apparently they deal with single entities. We look at the functional names and know full well that there would be multiple entities involved. And the very next service that comes along will need to use some of those entities and use the business logic which has now been locked away in a service specific implementation - what are you going to do? copy and paste the business logic from one to the other? or would you put 1000's of "if ... else .. if ... else ..."? Sorry, your implementation idea has so many flaws in it and flies in the face of years of experience and accumulated knowledge articulated by the likes of Martin.

                      I'm not sure what you didn't understand about my last paragraph - it was simply summing up my analysis of your implementation approach.

                      Let me restate my position: Service implementation does not belong  in the rich domain layer of an application, nor should it replace it. Instead, service implementation in a separate layer  (just  like the UI layer which is logically in) consumes the UI independent API of the rich domain layer. The Service implementation does indeed offer an API to consumers, however the rich domain layer of the application should not and need not have any knowledge or dependency on that. Let me show this again:

                      (consumer) --> UI (service layer) ---> PD (rich domain) <--- SI (consumer of some other service) 

                      The arrows indicate direction of dependency (i.e the PD is independent of any other layer which allows it to be an enduring layer for the business). N.B. Not bothering to show the data persistance, however you should know the persistance behaviour is applied directly to the business objects via the persistence frameworks (no need for DAO pattern anymore in the majority of applications).

                      Regards,
                      David.

                      > Which text of mine you read as "to implement business logic in consumer interaction specific code"? I never said so. Moreover, I explicitly pointed to the fact that consumer interaction specific code is the _secondary_ (if exists at all) to the business logic of the service. I said that this logic is defined at the service level - logical design level - and only implemented (not discovered) by objects. And service is not designed to handle any consumer specific code - it works against market and service composability/flexibility.
                      >
                      > Please, before calling my logic "Brittle", emember that services ARE NOT OBLIGED having consumer interaction code in sense of UI at all. Any consumer interacts with a service via its public interfaces; no object back -door.
                      >
                      > As of "procedural, hard to maintain code" - this admission only confirms that there are things in the business - business procedure - that objects are not the best modelling means for.
                      >
                      > Yes, "a company can  achieve  implementing a service... domain layer as an enduring layer of value" but not via placing new interface on a monolith application - Web Service interface does not make an application a service (because it does not enforces the application behave differently only because it is accessed via WS). But this is a different topic.
                      >
                      > If you dislike inheritance, let's take Spring and injections. Stupid EJB 3.0 and Spring allow objects to become self-persisted and linked with whatever messaging systems at the level of object. It is good for developers but not for architects who have to control access to resources and relationships between entities. If such self-contained object is moved into another execution environment where no messaging available or another messaging exist that the object is not prepared for, what it will do? I cannot use such object in the services because this creates dependency of the logical functionality from the mechanics of implementation, which is not acceptable in SO Ecosystem.
                      >
                      > It is the service who decides what data store or messaging to use, when, where and though which public interface. It is not a competence of the objects any more - we have created a higher layer of abstraction with services. This is what, I am afraid, you do not want to accept.
                      >
                      > Sorry, but I have not understood you last paragraph.
                      >
                      > - Michael
                      >




                    • Steve Jones
                      And this is where I disagree in as strong a way as possible. The concept of Enterprise Architects grasping the business challenges and creating some
                      Message 10 of 29 , Apr 10, 2013
                        And this is where I disagree in as strong a way as possible.  The concept of 'Enterprise Architects' grasping the business challenges and creating some 'enterprise architect' that includes everything in the business strategy is frankly laughable.

                        The 'gap' between business and IT is created specifically because of this arrogance on the IT side of it being some form of critical magic, the business runs the business, IT is there to help the business meet its goals, our objective is to 'deliver Christmas' to the business not to make them aware of all the crap and crud.

                        There are really good reasons why Enterprise Architecture has never been used to drive the structure or strategy of a business and equally good reasons why having a clear Business Architecture which directly drives into solution architecture without a layer of wooly thinking in between represents a better way of working.

                        It is IMPOSSIBLE in any large scale enterprise for there to be a single 'enterprise architecture' that makes any sense at the business level as the motivations and focus on the SAME topics differ across the business.  That is why BPR failed as an approach for instance and its madness to think that EA can succeed where BPR failed.

                        When we talk about things like Spring, EA or anything like that we must the fundamental point of how a business works as a value network, a value network that includes an ever increasing number of external services that we can never dicate to or manage directly.  Approaches that look at the internal and the small (OO) do not work there and approaches that attempt to manage and control it all (EA, BPR) do not work.  What works is understanding the domains of control (the services), their hierarchy (because that exists) and the value exchanges (capabilities) that exist.... this is the 'simple' view that gives clarity.

                        THEN worry about the specific technical approaches in each individual area as they may, indeed probably will, be different.

                        OO does NOT work as a single paradigm in this sort of environment and Enterprise Architecture is smoking something pretty special if it feels it can put forward a model that enables all of this to be managed under some sort of EA framework.

                        Can we please stop looking from IT upwards and start seeing what this looks like from the business perspective?  That isn't about REST, Spring, OO, JDBC or any other technical jargon, its about a value network and value exchanges.

                        Steve


                        On 10 April 2013 14:45, Ashraf Galal <ashrafwg@...> wrote:
                         

                        I disagree with your point. 
                        We have to look to the enterprise as the system and IT as subsystems.

                        We NEED tools for the management and change of enterprises.

                        The systems approach: viewing the enterprise itself as the main enterprise system, with the information system as a subsystem.

                        The general idea is that we have to be able to grasp both the enterprise system and the information system in a thorough and comprehensive way to be able to manage change.
                        We are trying to cross the gap between business and IT, not to pass the dilmma to the business.

                        All the best

                        Ashraf Galal





                        On 4/9/2013 3:24 PM, Michael Poulin wrote:
                         
                        Hi David,

                        what read all time in your comments is a pure IT viewpoint which I do not use anymore. This is why you do not understand me. See, you say "DI is used when your application needs to interact with another system (maybe via an enterprise service or maybe not depending on the situation). " In SOA Ecosystem, it is not a task because no one application needs to interact with another system - there are no such entities as an application that may need anything. _All_ applications must be inside services as their implementation; they cannot need anything but it is a service's business functionality needs another business functionality and outcomes regardless if there are systems, platforms or applications in that service.

                        Spring and similar frameworks work in millions applications but this does not make them more or less suitable for services. Numbers are not arguments. If a service gets limitations in composability because Spring used for implementation coupled it with particular database (or another application/package that is not included into this service's code base) , the service will not use such a solutions and will either spend resources to verify that such things will not be done in the code ever or (instead of spending resources)  simply will not use Spring framework at all because it is too risky and expensive to make work right.

                        If a business functionality of a service needs to work with many business informational entities, SE Ecosystem reserves a special type of services called Data Access Services (DAS). All source data is obtained from the data sources and persisted in these data sources via DAS. These services know the business semantic models used by different business services (their clients) as well as all technicalities and schemas of physical data storage, and perform data transformation where needed. This is why business services never own the data or data sources; they own only business semantic meta-models thwy know how to work with. It is a service that makes sense of actual data, not IT's DB or a canonical data model.

                        Two last points:

                        1) "however the rich domain layer of the application should not and need not have any knowledge or dependency on that [interface API]" - 100% agree with this.

                        2) "Service implementation does not belong  in the rich domain layer of an application, nor should it replace it. Instead, service implementation in a separate layer  (just  like the UI layer which is logically in) consumes the UI independent API of the rich domain layer. " - 100% disagree with this. Service implementation IS the rich domain layer comprised one or several applications or components (this is the preference of implementation only and may not impact service functionality and the outcome). Service is not an abstraction when it is implemented. And this implementation - the rich domain - must be implemented in compliance with Principles of Service Orientation. [If an application realises a business function but is constructed not in line with PSO, it requires a re-design and re-implementation to become a service. This is not done, such application may not be used in SO Ecosystem but can serve as a data resource].

                        This is all, David. I have said all I wanted to say.

                        Thanks,
                        - Michael





                        From: David Tildesley <davotnz@...>
                        To: service-orientated-architecture@yahoogroups.com
                        Sent: Sunday, April 7, 2013 2:26 AM
                        Subject: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

                         
                        Hi Michael,


                        --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
                        >
                        > David, if I disagree with Martin , it is OK and healthy if it makes sense. I am trying to explain this sense.

                        But what you are saying makes no sense. Martin makes perfect sense when he describes his enterprise patterns. You are saying he is wrong without providing a convincing argument as to why he is wrong. I believe it was Martin who first documented the IoC and DI patterns that Spring and other frameworks used today and tens of thousands of successful applications are delivered using. DI is used when your application needs to interact with another system (maybe via an enterprise service or maybe not depending on the situation). It keeps the domain layer free of dependency on these integrations with other systems.  Yes, data persistence has been relegated to the background with the more than capable frameworks (Hibernate, JPA, JDO etc.).

                        I wouldn't disagree with you about the "lipstick on a pig" approach that some significant vendors have taken to eek out the revenue stream on their "monolithic" applications by bolting on web-services.  Few, if any,  of these monoliths have been sensibly designed using good OO design approaches and many  still show their cobol heritage and many still have underlying cobol code. At least one large vendor has recognised that this approach needs to change and have started on that path by rebuilding their monolith(s) into functionally cohesive  blocks. Each of those blocks of course would take an OO approach to implementing the domain layer.

                        Finally, this latest explanation in your post is just like the previous - you are advocating an "entity" based service implementation all the way down to the data store itself. Your services have functional names but yet apparently they deal with single entities. We look at the functional names and know full well that there would be multiple entities involved. And the very next service that comes along will need to use some of those entities and use the business logic which has now been locked away in a service specific implementation - what are you going to do? copy and paste the business logic from one to the other? or would you put 1000's of "if ... else .. if ... else ..."? Sorry, your implementation idea has so many flaws in it and flies in the face of years of experience and accumulated knowledge articulated by the likes of Martin.

                        I'm not sure what you didn't understand about my last paragraph - it was simply summing up my analysis of your implementation approach.

                        Let me restate my position: Service implementation does not belong  in the rich domain layer of an application, nor should it replace it. Instead, service implementation in a separate layer  (just  like the UI layer which is logically in) consumes the UI independent API of the rich domain layer. The Service implementation does indeed offer an API to consumers, however the rich domain layer of the application should not and need not have any knowledge or dependency on that. Let me show this again:

                        (consumer) --> UI (service layer) ---> PD (rich domain) <--- SI (consumer of some other service) 

                        The arrows indicate direction of dependency (i.e the PD is independent of any other layer which allows it to be an enduring layer for the business). N.B. Not bothering to show the data persistance, however you should know the persistance behaviour is applied directly to the business objects via the persistence frameworks (no need for DAO pattern anymore in the majority of applications).

                        Regards,
                        David.

                        > Which text of mine you read as "to implement business logic in consumer interaction specific code"? I never said so. Moreover, I explicitly pointed to the fact that consumer interaction specific code is the _secondary_ (if exists at all) to the business logic of the service. I said that this logic is defined at the service level - logical design level - and only implemented (not discovered) by objects. And service is not designed to handle any consumer specific code - it works against market and service composability/flexibility.
                        >
                        > Please, before calling my logic "Brittle", emember that services ARE NOT OBLIGED having consumer interaction code in sense of UI at all. Any consumer interacts with a service via its public interfaces; no object back -door.
                        >
                        > As of "procedural, hard to maintain code" - this admission only confirms that there are things in the business - business procedure - that objects are not the best modelling means for.
                        >
                        > Yes, "a company can  achieve  implementing a service... domain layer as an enduring layer of value" but not via placing new interface on a monolith application - Web Service interface does not make an application a service (because it does not enforces the application behave differently only because it is accessed via WS). But this is a different topic.
                        >
                        > If you dislike inheritance, let's take Spring and injections. Stupid EJB 3.0 and Spring allow objects to become self-persisted and linked with whatever messaging systems at the level of object. It is good for developers but not for architects who have to control access to resources and relationships between entities. If such self-contained object is moved into another execution environment where no messaging available or another messaging exist that the object is not prepared for, what it will do? I cannot use such object in the services because this creates dependency of the logical functionality from the mechanics of implementation, which is not acceptable in SO Ecosystem.
                        >
                        > It is the service who decides what data store or messaging to use, when, where and though which public interface. It is not a competence of the objects any more - we have created a higher layer of abstraction with services. This is what, I am afraid, you do not want to accept.
                        >
                        > Sorry, but I have not understood you last paragraph.
                        >
                        > - Michael
                        >





                      • Ashraf Galal
                        I wonder if you grasp what I have said or not? Or attack is the best way for defense :) Sent from my iPhone. All the best Ashraf Galal
                        Message 11 of 29 , Apr 10, 2013
                          I wonder if you grasp what I have said or not?
                          Or attack is the best way for defense :)

                          Sent from my iPhone.

                          All the best

                          Ashraf Galal



                          On 2013-04-10, at 12:46 PM, Steve Jones <jones.steveg@...> wrote:

                          > system and the information system in a thorough and comprehensive way to be able to
                        • Steve Jones
                          I m pretty sure I understood what you were saying, it read like a standard EA pitch request to model the enterprise, map the IT systems and to do this on
                          Message 12 of 29 , Apr 11, 2013


                            I'm pretty sure I understood what you were saying, it read like a standard EA pitch request to model the enterprise, map the IT systems and to do this on behalf of the business (not pass the dilemma on to them).  My issue with that is that it appears to start with a big assumption.

                            Steve


                            On 10 Apr 2013, at 10:01, Ashraf Galal <ashrafwg@...> wrote:

                             

                            I wonder if you grasp what I have said or not?
                            Or attack is the best way for defense :)

                            Sent from my iPhone.

                            All the best

                            Ashraf Galal

                            On 2013-04-10, at 12:46 PM, Steve Jones <jones.steveg@...> wrote:

                            > system and the information system in a thorough and comprehensive way to be able to

                          • John Evdemon
                            ... Steve is spot-on here. This comment in particular reminds me of a Zachman presentation that summed up 40+ years of IT issues in a single slide. PDF format
                            Message 13 of 29 , Apr 11, 2013
                              On 10 Apr 2013 at 17:46, Steve Jones wrote:

                              > Can we please stop looking from IT upwards and start seeing what this
                              > looks like from the business perspective?

                              Steve is spot-on here. This comment in particular reminds me of a
                              Zachman presentation that summed up 40+ years of IT issues in a
                              single slide. PDF format - see #17: http://is.gd/R07nXY
                            • Ashraf Galal
                              Please do not put a personal guess. Unfortunatilly, your guess is not correct. The segragation between IT and business would not work for the indyutry at all!!
                              Message 14 of 29 , Apr 11, 2013
                                Please do not put a personal guess. 
                                Unfortunatilly, your guess is not correct.
                                The segragation between IT and business would not work for the indyutry at all!! It is very risky.
                                It might work for few individuals for some time.

                                All the best

                                Ashraf Galal

                                On 4/11/2013 10:23 AM, Steve Jones wrote:
                                 


                                I'm pretty sure I understood what you were saying, it read like a standard EA pitch request to model the enterprise, map the IT systems and to do this on behalf of the business (not pass the dilemma on to them).  My issue with that is that it appears to start with a big assumption.
                                 

                                Steve


                                On 10 Apr 2013, at 10:01, Ashraf Galal <ashrafwg@...> wrote:

                                 

                                I wonder if you grasp what I have said or not?
                                Or attack is the best way for defense :)

                                Sent from my iPhone.

                                All the best

                                Ashraf Galal

                                On 2013-04-10, at 12:46 PM, Steve Jones <jones.steveg@...> wrote:

                                > system and the information system in a thorough and comprehensive way to be able to


                              • Michael Poulin
                                Ashraf, I do not see any segregation between IT and business in Steve s words. He simply saying that the shoemaker should not bake cookies; it is a baker s
                                Message 15 of 29 , Apr 12, 2013
                                  Ashraf,

                                  I do not see any "segregation between IT and business" in Steve's words. He simply saying that the shoemaker should not bake cookies; it is a baker's job. The enterprise business should be designed by Business Architects, not Technical Architects even if they are called  Enterprise Architects. As of today, the latter are, in essence, Technical Architects.

                                  - Michael



                                  From: Ashraf Galal <ashrafwg@...>
                                  To: service-orientated-architecture@yahoogroups.com
                                  Sent: Thursday, April 11, 2013 8:27 PM
                                  Subject: Re: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

                                   
                                  Please do not put a personal guess. 
                                  Unfortunatilly, your guess is not correct.
                                  The segragation between IT and business would not work for the indyutry at all!! It is very risky.
                                  It might work for few individuals for some time.

                                  All the best

                                  Ashraf Galal

                                  On 4/11/2013 10:23 AM, Steve Jones wrote:
                                   


                                  I'm pretty sure I understood what you were saying, it read like a standard EA pitch request to model the enterprise, map the IT systems and to do this on behalf of the business (not pass the dilemma on to them).  My issue with that is that it appears to start with a big assumption.
                                   

                                  Steve


                                  On 10 Apr 2013, at 10:01, Ashraf Galal <ashrafwg@...> wrote:

                                   
                                  I wonder if you grasp what I have said or not?
                                  Or attack is the best way for defense :)

                                  Sent from my iPhone.

                                  All the best

                                  Ashraf Galal

                                  On 2013-04-10, at 12:46 PM, Steve Jones <jones.steveg@...> wrote:

                                  > system and the information system in a thorough and comprehensive way to be able to



                                • Ashraf Galal
                                  Michael, There is no broblem for having a BA doing business architecture for sure. My concern is: Business architect cannot be an Enterprise Architect, if he
                                  Message 16 of 29 , Apr 12, 2013
                                    Michael,
                                    There is no broblem for having a BA doing business architecture for sure.
                                    My concern is:
                                    Business architect cannot be an Enterprise Architect, if he comes from business area.
                                    Enteprise architect can be a busines architect and any kind of architectus in the same time.
                                    EA is consists of business, information and technologyg.
                                    BA is just modeling the business not managing or directing the business or manage technology.
                                     
                                    All the best

                                    Ashraf Galal


                                     
                                    On 4/12/2013 3:52 AM, Michael Poulin wrote:
                                     
                                    Ashraf,

                                    I do not see any "segregation between IT and business" in Steve's words. He simply saying that the shoemaker should not bake cookies; it is a baker's job. The enterprise business should be designed by Business Architects, not Technical Architects even if they are called  Enterprise Architects. As of today, the latter are, in essence, Technical Architects.

                                    - Michael



                                    From: Ashraf Galal <ashrafwg@...>
                                    To: service-orientated-architecture@yahoogroups.com
                                    Sent: Thursday, April 11, 2013 8:27 PM
                                    Subject: Re: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

                                     
                                    Pleasedo not put a personal guess. 
                                    Unfortunatilly, your guess is not correct.
                                    The segragation between IT and business would not work for the indyutry at all!! It is very risky.
                                    It might work for few individuals for some time.

                                    All the best

                                    Ashraf Galal

                                    On 4/11/2013 10:23 AM, Steve Jones wrote:
                                     


                                    I'm pretty sure I understood what you were saying, it read like a standard EA pitch request to model the enterprise, map the IT systems and to do this on behalf of the business (not pass the dilemma on to them).  My issue with that is that it appears to start with a big assumption.
                                     

                                    Steve


                                    On 10 Apr 2013, at 10:01, Ashraf Galal <ashrafwg@...>wrote:

                                     
                                    I wonder if you grasp what I have said or not?
                                    Or attack is the best way for defense :)

                                    Sent from my iPhone.

                                    All the best

                                    Ashraf Galal

                                    On 2013-04-10, at 12:46 PM, Steve Jones <jones.steveg@...>wrote:

                                    > system and the information system in a thorough and comprehensive way to be able to




                                  • Steve Jones
                                    I was kind of thinking that I hadn t mis-understood your point and... ... Why not? I m not sure why anyone would want to be an Enterprise Architect
                                    Message 17 of 29 , Apr 12, 2013
                                      I was kind of thinking that I hadn't mis-understood your point and...


                                      On 12 April 2013 16:50, Ashraf Galal <ashrafwg@...> wrote:
                                       

                                      Michael,
                                      There is no broblem for having a BA doing business architecture for sure.
                                      My concern is:
                                      Business architect cannot be an Enterprise Architect, if he comes from business area. 

                                      Why not?  I'm not sure why anyone would want to be an Enterprise Architect particularly but I see nothing to prevent someone who understands the business well being able to do EA if they so wish.
                                       
                                      Enteprise architect can be a busines architect and any kind of architectus in the same time.
                                       
                                      Which is what EAs always say, and its nonsense.  And why is it nonsense....

                                       
                                      EA is consists of business, information and technologyg.
                                      Because of this statement.  This myth at EA is some broad encompassing thing that includes the business strategy, because that is what business architecture is about, is one of the greatest pieces of hubristic arrogance that IT ever states.  Name me the business that uses an EA method to actually manage its business?  LEAN has GE, Kanban has Toyota, who is the EA reference for a strategy based around an EA approach?

                                      Saying that 'business people can't do architecture' is exactly what has got IT departments into the position of irrelevance that they often find themselves in today.  Saying that EA is something 'bigger' than the business and that business is just one 'aspect' is exactly the sort of statement that makes the business snort and walk away.
                                       
                                      BA is just modeling the business not managing or directing the business or manage technology.

                                      BA is 'just' modelling and managing the business.  It is certainly about managing the business and the people I've worked with who do genuine business remodelling based on value networks are certainly BAs who change the way a company works.  The key is that IT is like HR, its about enabling the delivery of the strategy.

                                      Business Architecture is about having the clarity on how the business works, how it will evolve and what measures will control that evolution.  Its a big thing, its a hard thing and it doesn't need EA to deliver.  The role of IT is to recognise that its a new world out there and claiming that EA's can govern and direct business is like claiming that Mr Bumble had control of his wife.

                                      And that is just why EAs don't make good Business Architects, they also often make awful solution architects as well as they don't have the technical detail required to effectively translate the business challenge into a simple solution, they can create a theoretical solution but do not have the required technical depth to make it work in a specific platform.

                                      Business Architecture to Solution Architecture and open standards is what is required, not Enterprise Architects pronouncing that they are bigger than the business and the business couldn't do their job, but they could do the business job.

                                      Steve

                                       
                                       
                                      All the best

                                      Ashraf Galal


                                       
                                      On 4/12/2013 3:52 AM, Michael Poulin wrote:
                                       
                                      Ashraf,

                                      I do not see any "segregation between IT and business" in Steve's words. He simply saying that the shoemaker should not bake cookies; it is a baker's job. The enterprise business should be designed by Business Architects, not Technical Architects even if they are called  Enterprise Architects. As of today, the latter are, in essence, Technical Architects.

                                      - Michael



                                      From: Ashraf Galal <ashrafwg@...>
                                      To: service-orientated-architecture@yahoogroups.com
                                      Sent: Thursday, April 11, 2013 8:27 PM
                                      Subject: Re: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

                                       
                                      Pleasedo not put a personal guess. 
                                      Unfortunatilly, your guess is not correct.
                                      The segragation between IT and business would not work for the indyutry at all!! It is very risky.
                                      It might work for few individuals for some time.

                                      All the best

                                      Ashraf Galal

                                      On 4/11/2013 10:23 AM, Steve Jones wrote:
                                       


                                      I'm pretty sure I understood what you were saying, it read like a standard EA pitch request to model the enterprise, map the IT systems and to do this on behalf of the business (not pass the dilemma on to them).  My issue with that is that it appears to start with a big assumption.
                                       

                                      Steve


                                      On 10 Apr 2013, at 10:01, Ashraf Galal <ashrafwg@...>wrote:

                                       
                                      I wonder if you grasp what I have said or not?
                                      Or attack is the best way for defense :)

                                      Sent from my iPhone.

                                      All the best

                                      Ashraf Galal

                                      On 2013-04-10, at 12:46 PM, Steve Jones <jones.steveg@...>wrote:

                                      > system and the information system in a thorough and comprehensive way to be able to





                                    • David Tildesley
                                      Hi Michael, You continue to be laboring under the illusion that attacking OO is in some unexplained way, a necessity to defending or promoting SOA as if they
                                      Message 18 of 29 , Apr 19, 2013
                                        Hi Michael,

                                        You continue to be laboring under the illusion that attacking OO is in some unexplained way, a necessity to defending or promoting SOA as if they are in some unexplained way, in competition with each other.

                                        "D = Domain" in DDD is about a business driven, consensus based, OO design approach to modelling just (and only) the (rich) domain layer for some application or some component bounded by the scope of a problem domain (big or small). The patterns that were mentioned are about protecting that layer in order to make it of enduring value to the business in the largest variety of usage contexts.

                                        Using a DDD approach to designing an application or some functionally cohesive component (that may have resulted from the business taking a SOA approach), is irrelevant to whether the organisation takes a SOA approach or not.

                                        DDD and SOA are not mutually exclusive or in tension. An organisation would be silly to abandon DDD when taking up a SOA approach just because they have an illusion that they are somehow in tension.

                                        However DDD and SOA share something vital in common - they both "bridge the area between business and IT".

                                        They also share the irony that they are seldom practiced by organisations yet blamed in their absence.

                                        David.


                                        To say every integration is
                                        --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
                                        >
                                        > Hi David,
                                        >
                                        > what read all time in your comments is a pure IT viewpoint which I do not use anymore. This is why you do not understand me. See, you say "DI is used when your application needs to interact with another system
                                      • Michael Poulin
                                        Hi David, You say DDD and SOA are not mutually exclusive or in tension , and I totally agree with you on this. The only one point I try to make all this time
                                        Message 19 of 29 , Apr 21, 2013
                                          Hi David,

                                          You say "DDD and SOA are not mutually exclusive or in tension", and I totally agree with you on this.

                                          The only one point I try to make all this time - SOA requires that no one piece if code used for its implementation may cross physical service's boundaries; DDD does not have such constraint and, in general, allows that domain oriented components (compositions of objects) can share some common libraries, packages, POJO, etc. That is, if a DDD-modelled component is a "bag", nothing prevents developers to tie a chain of small sacks to the bag's handle and, moreover, tie another end of this chain of sacks to another bag. This is why  I say that 'DDD and SOA are not mutually exclusive' but one supervise another, and this one is Service.

                                          - Michael



                                          From: David Tildesley <davotnz@...>
                                          To: service-orientated-architecture@yahoogroups.com
                                          Sent: Friday, April 19, 2013 11:25 AM
                                          Subject: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

                                           
                                          Hi Michael,

                                          You continue to be laboring under the illusion that attacking OO is in some unexplained way, a necessity to defending or promoting SOA as if they are in some unexplained way, in competition with each other.

                                          "D = Domain" in DDD is about a business driven, consensus based, OO design approach to modelling just (and only) the (rich) domain layer for some application or some component bounded by the scope of a problem domain (big or small). The patterns that were mentioned are about protecting that layer in order to make it of enduring value to the business in the largest variety of usage contexts.

                                          Using a DDD approach to designing an application or some functionally cohesive component (that may have resulted from the business taking a SOA approach), is irrelevant to whether the organisation takes a SOA approach or not.

                                          DDD and SOA are not mutually exclusive or in tension. An organisation would be silly to abandon DDD when taking up a SOA approach just because they have an illusion that they are somehow in tension.

                                          However DDD and SOA share something vital in common - they both "bridge the area between business and IT".

                                          They also share the irony that they are seldom practiced by organisations yet blamed in their absence.

                                          David.

                                          To say every integration is
                                          --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
                                          >
                                          > Hi David,
                                          >
                                          > what read all time in your comments is a pure IT viewpoint which I do not use anymore. This is why you do not understand me. See, you say "DI is used when your application needs to interact with another system



                                        • Steve Jones
                                          Ok I m going to disagree with one point here... SOA requires that no one piece if code used for its implementation may cross physical service s boundaries;
                                          Message 20 of 29 , Apr 21, 2013
                                            Ok I'm going to disagree with one point here...

                                            "SOA requires that no one piece if code used for its implementation may cross physical service's boundaries;"

                                            Why? For me SOA doesn't give a monkey if you use the same code in two different services.  I can even see an occasion (Vendor Management Inventory) where one service could deploy within the management context of another some code (for instance a business process) to enable it to deliver its capabilities.

                                            SOA is for the architecture, OO and DDD are for the boundaries within services (along with BPM, COBOL, ABAP, people, etc, etc).  But SOA doesn't restrict code movement and I could certainly design a perfectly valid service whose capability is logistically within the bounds of another but whose capability firmly remains the responsibility of the originating service.

                                            Steve


                                            On 21 April 2013 18:52, Michael Poulin <m3poulin@...> wrote:
                                             

                                            Hi David,

                                            You say "DDD and SOA are not mutually exclusive or in tension", and I totally agree with you on this.

                                            The only one point I try to make all this time - SOA requires that no one piece if code used for its implementation may cross physical service's boundaries; DDD does not have such constraint and, in general, allows that domain oriented components (compositions of objects) can share some common libraries, packages, POJO, etc. That is, if a DDD-modelled component is a "bag", nothing prevents developers to tie a chain of small sacks to the bag's handle and, moreover, tie another end of this chain of sacks to another bag. This is why  I say that 'DDD and SOA are not mutually exclusive' but one supervise another, and this one is Service.

                                            - Michael



                                            Sent: Friday, April 19, 2013 11:25 AM

                                            Subject: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

                                             
                                            Hi Michael,

                                            You continue to be laboring under the illusion that attacking OO is in some unexplained way, a necessity to defending or promoting SOA as if they are in some unexplained way, in competition with each other.

                                            "D = Domain" in DDD is about a business driven, consensus based, OO design approach to modelling just (and only) the (rich) domain layer for some application or some component bounded by the scope of a problem domain (big or small). The patterns that were mentioned are about protecting that layer in order to make it of enduring value to the business in the largest variety of usage contexts.

                                            Using a DDD approach to designing an application or some functionally cohesive component (that may have resulted from the business taking a SOA approach), is irrelevant to whether the organisation takes a SOA approach or not.

                                            DDD and SOA are not mutually exclusive or in tension. An organisation would be silly to abandon DDD when taking up a SOA approach just because they have an illusion that they are somehow in tension.

                                            However DDD and SOA share something vital in common - they both "bridge the area between business and IT".

                                            They also share the irony that they are seldom practiced by organisations yet blamed in their absence.

                                            David.

                                            To say every integration is
                                            --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
                                            >
                                            > Hi David,
                                            >
                                            > what read all time in your comments is a pure IT viewpoint which I do not use anymore. This is why you do not understand me. See, you say "DI is used when your application needs to interact with another system




                                          • Michael Poulin
                                            David, probably, I was not accurate enough: a code implementing a service A may be used in a service B as well but those service do not share the instance of
                                            Message 21 of 29 , Apr 22, 2013
                                              David,
                                              probably, I was not accurate enough: a code implementing a service A may be used in a service B as well but those service do not share the instance of this code - each code instance together with any referred code must stay inside the service boundaries. This allow me to move the services wherever and whenever I need with no looking around (which other services would be affected).

                                              If SOA is for architecture, no one design method may violate this architecture. Architecture of the service is about business functionality of the service first, its outcome/RWE second, executions context (policies) and only then - interfaces.

                                              Each service has its own independent owner (according to OASIS standards). If a service's capability (in full) belong to another service (under different ownership) the first service does not make sense because it does not realise any business functionality and offers new business value (on its own). Another case is when a service is an aggregate service, which combines several capabilities provided by several other services. In this case, the capability of the initial service is the aggregation logic, nothing more; other capabilities/services are just contracted.

                                              - Michael


                                              From: Steve Jones <jones.steveg@...>
                                              To: service-orientated-architecture <service-orientated-architecture@yahoogroups.com>
                                              Sent: Sunday, April 21, 2013 11:05 PM
                                              Subject: Re: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

                                               
                                              Ok I'm going to disagree with one point here...

                                              "SOA requires that no one piece if code used for its implementation may cross physical service's boundaries;"

                                              Why? For me SOA doesn't give a monkey if you use the same code in two different services.  I can even see an occasion (Vendor Management Inventory) where one service could deploy within the management context of another some code (for instance a business process) to enable it to deliver its capabilities.

                                              SOA is for the architecture, OO and DDD are for the boundaries within services (along with BPM, COBOL, ABAP, people, etc, etc).  But SOA doesn't restrict code movement and I could certainly design a perfectly valid service whose capability is logistically within the bounds of another but whose capability firmly remains the responsibility of the originating service.

                                              Steve


                                              On 21 April 2013 18:52, Michael Poulin <m3poulin@...> wrote:
                                               
                                              Hi David,

                                              You say "DDD and SOA are not mutually exclusive or in tension", and I totally agree with you on this.

                                              The only one point I try to make all this time - SOA requires that no one piece if code used for its implementation may cross physical service's boundaries; DDD does not have such constraint and, in general, allows that domain oriented components (compositions of objects) can share some common libraries, packages, POJO, etc. That is, if a DDD-modelled component is a "bag", nothing prevents developers to tie a chain of small sacks to the bag's handle and, moreover, tie another end of this chain of sacks to another bag. This is why  I say that 'DDD and SOA are not mutually exclusive' but one supervise another, and this one is Service.

                                              - Michael



                                              Sent: Friday, April 19, 2013 11:25 AM

                                              Subject: [service-orientated-architecture] Re: Richard Pawson comment on BPM/Workflow

                                               
                                              Hi Michael,

                                              You continue to be laboring under the illusion that attacking OO is in some unexplained way, a necessity to defending or promoting SOA as if they are in some unexplained way, in competition with each other.

                                              "D = Domain" in DDD is about a business driven, consensus based, OO design approach to modelling just (and only) the (rich) domain layer for some application or some component bounded by the scope of a problem domain (big or small). The patterns that were mentioned are about protecting that layer in order to make it of enduring value to the business in the largest variety of usage contexts.

                                              Using a DDD approach to designing an application or some functionally cohesive component (that may have resulted from the business taking a SOA approach), is irrelevant to whether the organisation takes a SOA approach or not.

                                              DDD and SOA are not mutually exclusive or in tension. An organisation would be silly to abandon DDD when taking up a SOA approach just because they have an illusion that they are somehow in tension.

                                              However DDD and SOA share something vital in common - they both "bridge the area between business and IT".

                                              They also share the irony that they are seldom practiced by organisations yet blamed in their absence.

                                              David.

                                              To say every integration is
                                              --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
                                              >
                                              > Hi David,
                                              >
                                              > what read all time in your comments is a pure IT viewpoint which I do not use anymore. This is why you do not understand me. See, you say "DI is used when your application needs to interact with another system






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