Tuesday, July 25, 2006

SOA Friendly Architecture version of Jeffrey Palermo's Architecture -- Part 2 -- Architecture

As always, Survic raised excellent Questions and gave excellent suggestions about my previous post. Survic comments/questions are in bold.


“Business Object Manager” (I guess it is the “Façade Object” -- it is very popular to use "XX_Manager" and "XX_Facade" interchangeably)Business Object Manager is a Mediator between Business/Entity Object and Data Object Layer. It provide an opportunity to aggregate the business objects on Database server and send aggregate object at once to Application Server. This particular element is missing in Jeffery’s Architecture (I could be wrong) or in Pet Shop Architecture (I am very sure because I am burnt by it).
It also enables Business Object Layer and Business Transfer Object to one layer instead of being multiple layers as shown in the code.


Process Object” (I guess it is the “Workflow Object”)


Yes, Survic is right.
All the Workflow logic, additional processing, co-ordination and control logic will go there.


Repository Object” (I’m pretty sure it is the “Façade Object”).
In my case, it is responsibility of Gateway/Factory Layer. I may take out of Architecture diagram.

Application architectures” and “service architectures” are critically different?No. There are subtle but major Design differences.

SOA = Good Distributed Programming Practices + Message Version Control + More Loose Coupling
In Distributed Architecture/Client Server Architecture, generally you may have control over client applications. In my internal application architecture, I can make changes to Business Object layer and regenerate the proxy object and recompile the Gateway/Factory Layer and make changes to UI. So there is little tight coupling between server side component and consumer application. Basically I am sharing code with Consumer application. Performance is big concern. It is more RPC style of communication
Distributed computing is also more end-to-end integration. Component A connects to Component B and component B connects to Component C

In Service Oriented Architecture, you don't have control over client applications or other consumer Services. in general. You have to be more subtle over version control. You share contract and chances are that your application may support multiple contracts.In that scenario, I design the Incoming message as XML string and share XML Schema with client. That way Interface of Service always remain same (no need to regenrate WSDL )but you message structure may change. It is more Document Style of communiction.
SOA is more like workflow. Component A may connect to Componet B or may be Component C.
Here is nice article by Rockford Lhotka

However I think that if you have good Middle Layer, adding a true service layer should be a small issue.

Microsoft Architectue
Do they have some implementation code? My interpretation is same like you. It is decent architecture if we both are right. Last time , I used pet shot .net architecture, it left a very bad taste in mouth. :)

3 comments:

survic said...

Just come back from a trip...

I agree with your post; however, I also see the subtle and interesting differences.

I noticed you mentioned three things at the end of your post (a) “It is more Document Style of communication”; (b) “SOA is more like workflow”; (c) “However I think that if you have good Middle Layer, adding a true service layer should be a small issue”.

My whole arguments are based on those three points. If you build entity objects (including containment – i.e. “aggregated entity objects, and also including “value objects”) and some necessary DTOs (data transfer objects), then, they can be changed to XML easily. Then, when it is necessary, we can simply select some façade and workflow objects as the services. Perhaps sometimes we need to make it even more coarse-grained; but we do that all the time within façade and workflow layers anyway– that is the very nature of façade and workflow layers: constantly changing to reflect business workflow/use-case changes.

Put it in another way: in classic asp or servlet or cgi (note that asp.net hides more, so, I would not use it here as an explanation tool, but I will use it later, see below), the response is html based; web service is xml based. That is the only real difference. You may say, “we need more standards and therefore specs in web services”, true, but that is what xml implies.

However, we all know asp.net and classic asp are both in the “application architecture”. Asp.net makes things more like winform by using postback. Ajax/Atlas makes it even more so.

I guess we can safely say that we all agree that SOA is adding (not changing, simply adding) another half a layer (not even a whole layer) that is similar to “workflow” layer, and is more document-oriented and message-oriented communication.

As for the differences, they really depend on the context. I can easily imagine that I can argue a SOA is very different from an Application Architecture when I am focusing designing the half layer of the service, when I need to zoom in, and amplify details.

I guess the key reasons that I want to point out that there are not big differences are that (a) SOA’s new stuff is an addition; (b) the crucial business logic (“domain logic”) is in the business layer. As a result, for an application developer, SOA is the plumbing, or, even just a “distraction”. (My impression is that Rocky also holds the same attitude, but via a different route though – very interesting)

Vikas said...

I guess we can safely say that we all agree that SOA is adding (not changing, simply adding) another half a layer (not even a whole layer) that is similar to “workflow” layer, and is more document-oriented and message-oriented communication.

Cannot disagree with this comment.

Vikas said...

Survic wrote
"I guess we can safely say that we all agree that SOA is adding (not changing, simply adding) another half a layer (not even a whole layer) that is similar to “workflow” layer, and is more document-oriented and message-oriented communication.
"

One thing that I think that driving this layer without requirements is very difficult. With out requirement, one is simply shooting in dark and will cause him despair. But if you have requirements, adding this layer is very easy.