Services vs. OO


EJB design: Services vs. OO

  1. Services vs. OO (2 messages)

    As someone who develops J2EE apps via OO methodologies, I'm curious as to how services and service-oriented architectures (SOA) fit with traditional OO?

    The mismatch I have is that I was always taught to write use cases across the entire scope of the system, which in turn become objects with properties and behaviour, with certain objects naturally coupling to others to form subsystems. The SOA approach maps technology to business processes and is described as “an application architecture within which functions are defined as independent services with well-defined interfaces which can be called to form business processes”.

    If an SOA approach is taken, then the overall scope of the system (fairly large on my project) must be functionally decomposed by business process, yet functional decomposition is described as a common OO anti-pattern. To quote, “avoid the temptation to use a functional view of the system as a basis for the creation of an object-oriented architecture”.

    So what’s the answer here? What are the series of steps I can take to get from analysis to Java code, whilst maintaining the principles of a service-oriented architecture and loosely-coupled components?



    Threaded Messages (2)

  2. Services vs. OO[ Go to top ]

    Good question, and topical. Here's my view:

    OOAD is most suitable for modelling a domain, that is, the classes and objects out in the real world. Eg, customers, products, trucks, containers, companies, contacts, etc. These exist whether you do or not.

    OOAD is less suitable (IMO) for the added-value that you bring to the domain, because what you are bringing is applications that can use and manipulate the domain model in some way to provide a good or service to your client.

    Those applications are the "what gets done to the domain model" (the use-cases) and are therefore _behaviour_, which is better modelled as services.

    Hence you have the service-oriented applications, built on top of the object-oriented domain model.

    By all means put behaviour in the domain model, but it should be domain behaviour, ie. applicable over all use cases.

    Of course, this is a simplistic view and complex domains and applications don't split up so neatly. But this is how I see it in an ideal world.

    Don't know if that makes sense or helps at all.

  3. Services vs. OO[ Go to top ]

    That's a very nice summary, Kit.