Service Architecture Concept Model


I'm posting this because I'm interested in your thoughts about it.


A Service Architecture Concept Model


IMPORTANT: This is just a concept illustration. I'm not encouraging anyone to accept and begin using the nomenclature used.


This is just the result of a conversation Tom and Ed and I had today about how this illustration might evolve. If something isn't clear, please leave a comment. If you've seen other illustrations or nomenclature about these things that better resonate with you, please leave a comment and tell me about them. If you have any other thoughts, ... I think you get the idea 🙂

http://dev4net.members.winisp.net/images/conceptmodel.png

Comments (9)
  1. ChilliCoder says:

    In the original drawing, the business layer includes an element on top of Business Logic (BL) and Business Entities (BE), it’s named Service Interface but guess that here could be named Business Interface. What should be there? The means of interacting with the BL & BE. I see the elements of the Service Interface Layer interacting with the Business Layer via the Business Interface and not directly calling the BE’s and executing BL.

  2. Looks awesome Don (even better than when we scribbled it on our whiteboard yesterday 🙂

    A few suggestions:

    – The cross-cutting concerns should probably extend to the data sources within the service boundary

    – Ed’s original diagram had "Business Workflows" in the business layer – I think this is still a nice concept that still fits in this layer (even though Service Factory doesn’t have much to say about this yet!)

    – I’m not sure the resources (data sources and other services) should be the same color as the resouce access layer. And everyone knows databases are yellow 🙂

    Chillicoder – I think the Service Interface Layer is the same as the Service Interface shown on the original diagram, which is distinct from the business layer. Every layer has some kind of entry point used by higher layers but this isn’t shown on the diagram. The SI Layer is more important since it’s the entrypoint for callers outside of the service boundary.

    I’m very interested to hearing what everyone else thinks about this proposal too!

    Tom

  3. Herman says:

    IBM has a similar chart "The layers of a SOA" (http://www-128.ibm.com/developerworks/webservices/library/ws-soa-design1/). You may be interested on taking a look. Both charts are

    awesome.

  4. Steven says:

    This is me being picky…

    Why explicitly name a component "Business Logic" within the BL? Logic is encapsulated within Entities, Aggregators and Workflow.

    A Typo perhaps? Don’t be shy Don, you can say you meant to write Workflow instead of Logic.

    😉

  5. LockSmithDon says:

    No, it’s not a typo. One of the things we’re trying to do is provide a name to each layer: Service Interface Layer, Business Layer, and Resource Access Layer (new term).

    The one thing I did fail to do in this graphic is include the Business Workflows (that was an accident). I’ll fix it later and these comments won’t make any sense 🙂

    In the Business Layer, the Business Entities,  Business Logic, and Business Workflows should be separate since because of their (loose) level of coupling to each other.

    Of course, if you’re looking for typos, just hang around for a while … it won’t take long 😉

  6. Steven says:

    I still maintain that Business Logic is not a component per say of the BL.  IMO, business logic is like the Matrix…The Matrix is everywhere. In a way, it’s the glue that ties together elements of the likes of entities, components and workflow.

    Still I have another small observation.  Isn’t it redundant naming the interface layer the "Service" interface layer.  If not so then wouldn’t we be intitled to say that in fact we must not only say that we have a Business Layer but instead a "Service" Business Layer.  Same goes for the RAL – new term which I give a thumbs up to.

    So I would be inclined to rename that first layer in the following fashions:

    -Message/Messaging Layer

    -Contrat Layer

    And since I’m keen on the "Interface" terminology – then again couldn’t we see it also as a facade of the different operations rendered by the service – I’d also go along the lines of:

    -Message/Messaging Interface Layer

    -Contrat Interface Layer

    For the sake of the argument, let’s say we give ourselves the liberty to not think of the notion to much and say it’s a facade…then I’d prefer:

    -Contract/Message Facade Layer

    Then again…sleep deprived…I may not be making any sense right now…  😉

  7. Jerry Nixon says:

    Beautiful. I just stole it!

    Seriously, beautiful.

    The cross-sections might include a Performance/Health/Monitoring chunk, you think? You could wrap it into management, I guess. Who am I kidding? I don’t like cross-cutting stuff in this diagram anyway. Nobody really reads the sideways stuff anyway.

    Great work.

  8. serge says:

    hi every body,

    I am not so deep involve on archiutecture design compare to you guys. I am mire front developper site for teh time beeing. Around all things I could read around on architecture I have see in most places that the Buisness Layee is between the Presentation Layer and the data layer when you look on a 3 tier model.

    I you ask me where I could place the Service layer, I would think it logic to have it between the Buisness Layer and the Data LAyer.

    For me sounds more familar to say that my user use this my aplpication interface, then I will check if my buisness rules are validated before calling a particular service…

    I might be wrong of course depending on your comments that justify this order.

    I am actually deep in an architecture thinking for my new application and I start to loos my hairs to know where to place what.. And my last drawing path is for my alarming system:

    – presentation Layer

        . Active alarm UI

        . HIstory alarm UI

    – Buisness Rules

        . Active alarm management

        . History alarm management

    – Service Layer

        .  Alarms statiscs

        .  Alarms publishing

        . Alarms tracking

    – Data Layer

        . Store alarm history

    In that last drawing path I was thinking of, I still do not know in which form those component will be ( web service, remoting,Windows services..)

    Your comment are welcome..

    Once again I ma not an architect expert

    Serge

  9. Many times the services are just part of a service layer interface or facade that only delegate calls

Comments are closed.

Skip to main content