Let's say I have two applications that needs to communicate with each other. In a nutschell, when I design an application (not always of course), I have my business component (Facade Layer), data access component, and my domain objects (DTO's), which makes up three seperate assemblies.
Now, let's say I am building the Sales & Marketing application that needs to communicate with the Accounting components. I am not sure if the Sales application should just go ahead and make direct references to the accounting assemblies or if I should go ahead and put a web service proxie in front of the components. The environment I work in is all Microsoft based and our applications are used internally by our divisions.
Any thoughts, advantages/disadvantages
Middle Tier Design Question
groves
Just a thought here, I find it interesting that your domain objects are referred to as DTO's this is usually not the case. You also mention a business facade which leads me to believe you are using a transaction script based setup
Eric Evans discusses in his book "Domain Driven Design" (which I highly recommend btw) different mechanisms of dealing with your issue and the pros and cons of each .. Basically what you are dealing with are different contexts and how to manage the information from context to context.
Personally I like to go a similar route to what you mention (the XML forces abstraction between the two contexts) but I prefer to do it within my domain itself. Thus my Sales and Marketting domain would have a "Service" within it that allowed access to the accounting system. This service would then use the webservice to communicate with the other domain.
Again, I cannot recommend this book enough; there is also a C# focused DDD book coming out from Jimmy Nilsson which offers C# specific guidance to many of the concepts found in DDD and in P of EAA http://www.amazon.com/exec/obidos/tg/detail/-/0321268202/qid=1142719078/sr=2-1/ref=pd_bbs_b_2_1/102-3319163-1611303 v=glance&s=books
BogdanZ
well .. there is actually a pattern describing your methodology from what I see (it is called an anemic domain http://www.martinfowler.com/bliki/AnemicDomainModel.html don't take offense to the read it is actually quite common when SOA comes into the picture to end up with thin DTOs and a ton of services (business components) using them. I may be wrong, but this is what it sounds like is happenning.
"I will definetly put that book on my list of books to read and devour, but in a nutshell, could you tell me the benefits of using direct references to assemblies, rather than using web services "
Well in general I would say a better rule would be to use the webservice because it puts in a layer of abstraction between the two domains and allows the complete hiding of the second domain from the first (very thin contract). That said this layer of abstraction comes at a price. You might be better off in some circumstance to do things like provide a public contract for the other system then dynamically load it (far less overhead).
"Also, in your domain designs, do your business components get their data via web services, or do you only use service agents when you need to communicate with external applications "
It depends, if I am getting data from another system it will often be through a repository, if I am telling the other system perform an action for me (verb) it will be through a service.
Greg
simran
The reason for my seperation is because I use an O/R mapper for my data acess (LLBLGenPro), so I need this extra service layer in order to encapsulate my domain logic.
Also, what do you mean by repository I thought the service would be responsible for actions and retrieving data.
Jeff_R
Just as a side note ... There is almost no mention of remoting here which in a completely MS based environment where you are not dealing with unknown external clients is often times a better solution than webservices, although the concepts are becoming alot closer with WCF (indigo)
4kapple
Before you go about deciding what technology to use between the components. You should spend some time thinking about their interaction. Distributed computing is different (take a look at the 8 fallacies of distributed computing). Making the Accounting component accessible via web-services also means it is a remote components and the implications are much greater than just the mere technology choice.
Arnon
beaker101
Thanks for your reply!
I guess I should not have called them domain objects, b/c they are really just data containers and my business components contain the actual domain logic.
I work within a complex domain, so in order to simplify the life of the UI developers, I added another layer that sits above the business components, the facade, whose sole resposibility is to provide a simpler interface to work with.
I will definetly put that book on my list of books to read and devour, but in a nutshell, could you tell me the benefits of using direct references to assemblies, rather than using web services
Also, in your domain designs, do your business components get their data via web services, or do you only use service agents when you need to communicate with external applications
Thanks again!
Sam43
I do not llblgen very much myself, I prefer systems which do not couple my domain to themselves. If you need to change out llblgen at this point you are in a pretty bad situation as your objects are strongly coupled to it nhibernate, gentle.net 2.0, and wilson O/R all do a better job of handling this.
When I say that it is a respository, there are 2 functional "services" in my domain .. services which provide verb like actions and repositories which provide access to data.
i.e. in your example with Sales & Marketting + Accounting ..
I might have a
SalesPersonPersonRepository which is responsible for the finding/loading/saving of sales people and an AccountingService which has methods such as GetMeSomeAccountingInformation
MalcolmGreene
Hi!
I think best thing to do is to write web service for accounting part, so other parts can make high-level queries to it.
If you make dynamic web services references in client projects, then they can easily be pointed to other location later.
You can also make facade assembly, that will be loaded by clients and know how to call accounting, but I think it's much more work and this assembly must be installed to each client computer (web service need no installation) and it must be not referenced by client, but loaded at runtime... too much things to keep in mind. Web services easier to use here.