I’m working on an application which has been designed using n-tire application architecture .The application was developed in the .NET platform utilizing C#,VB.NEt, Framework 3.5, Dataset, WCF, asp.net update panel, JavaScript ,Josn, 3rd Party tools.
my current proposed layout is such
presentation layer -> Business Logic -> WCF -> DAL->Data access
The point Is:
Is the above layout the right way to build SOA systems ?
As always, your advice is greatly appreciated
This depends on your definition, see Fowler's comments.
Generally, in order to get the most benefit from something SOA, you're services should be designed to be reusable by multiple consumers. This means placing your business logic "beneath" your WCF layer. Then you can have, for instance, a Silverlight client, a WPF client, etc. using the same services and business logic.
Change your scenario to:
Multiple Presentation Layers -> WCF -> Business Logic -> DAL-> Data access
Looks like it COULD be correct although I'd put WCF between your Pres and Biz layers too. Also, don't be afraid of having a non-linear path for your SOA architecture (i.e. having side services like an "EmailService" and "WeatherDataService" that come from the side of your N-Tier path. Obviously the WeatherDataService would come from the side of your DAL but the EmailService might come from the side of your Biz layer.
Some great links for you:
Doing N-Tiers with WCF
WCF and Datasets with N-Tiers
N-Tier with WCF, MVC, and LINQ
Your services should be business operations, not data operations. A better version of your design would be:
presentation layer -> WCF -> Business Logic -> Data access.
N-tier / layering is a pretty dated concept these days. It always broke down. Instaed, think of your software as a number if interacting services.
Related
I'm about to create a new imposing web project using Play! framework (similar to Rails philosophy).
After reading some important parts of this famous book: Service-Oriented Design with Ruby and Rails for learning some tips on good design, I wish to avoid monolithic application by creating separated Play! applications as services layers (through REST).
Thus, I imagine the first Play! application would be responsible for routing clients' requests to remote services layers contained each one in other Play! applications.
I wonder both things with this solution:
Where to put Entities/Values Objects (data model)? May there be some kind of data-model.jar shared between view application and services applications? (Optional for view since DTO's or JSON object would be sufficient)
View application would end up with no model layer, since view application acts as a simple proxy for services applications. Doesn't it promote confusion or potential bad understanding for future developers (an application with view/controller but without model part)? Likewise, services applications wouldn't contain view layer...
In short, each of these applications using Play! would seem to follow this bad principle: YAGNI
I'm in the situation that I have to design and implement a system from the scratch. I have some questions about the architecture that I would like your comments and thoughts on.
Quick Info about the project: It's a data centric web application.
The application will be built on Microsoft .NET Framework 4.0 with MS SQL SERVER 2008 database.
Requirement:
Rich UI and robust
Multi-device support (every browser and on every device)
Loosely coupled
Below is the architectural diagram I have built:
Briefing of the architecture
Presentation layer : HTML5/ASP.NET MVC + JQuery (Web application for multi-device support in first version)
Distributed Services : WCF (XML/JSON/JSONP)
Domain Layer(Business Layer) : All business logic
Data persistence (DAL Layer) : Entity Framework 4.0 with database first approach. POCO entities are generated and separated out using T4 template
Infrastructural Layer: Contains common libraries like POCO entities, Exception Handling, logging etc
My Concerns :
As application is to be built loosely coupled so in future if business requirement grows new modules can be easily plugged in without affecting the architecture.
So I thought of using the Repository pattern along with IoC and DI (can be Unity/Ninject/Sprint.NET or any other)
WCF with both XML and JSON support
Distributed Service Layer to place IoC & DI
Exception Handling & Logging using Enterprise Library 5.0
Looking for valuable comments and suggestions.
If I am doing anything wrong please put me in right direction.
I would suggest the following comment: right from the outset your approach will create tight coupling. This goes directly against your requirement #3 "Loosely coupled"
In your diagram you have defined two modules. Main module, and Module 2. I would guess that these two modules are quite distinct from each other. What I mean by this is that you could develop them completely separately and then plug them in, because the business concerns they address are different.
However, your current architectural approach:
Couples Main Module and Module 2 data into the same database
Couples Main Module and Module 2 business objects into the same business layer
Couples Main Module and Module 2 services into the same service layer
Couples the deployment and management of Main Module and Module 2
What may be worth considering: Build Main Module and Module 2 as separate vertical service stacks.
What I mean is Main Module and Module 2 become Main Service and Service 2
Each service has it's own database, it's own business layer, it's own services layer and it's own UI components.
However, this raises the concern: how can Main Service and Service 2 both work together to create my product?
To address this:
At the UI end, you stitch your front end together by using client-side code to load responses from the Main Service and Service 2 into one view.
At the back end you use publish subscribe messaging to allow Main Service to subscribe to events happening in Service 2 and vice versa.
This will result in an application built from the ground up on top of loosely coupled vertical service stacks, which maintain consistency by the asynchronous exchange of messages.
If you then need to add in a new module to your application, you can create a new service stack which supports the desired capability and wire it up with little or even no change needed to the other stacks (ideally the only reason to change existing stacks would be that they want to subscribe to events from the new module).
It's a very different approach to the one you're suggesting, but one which allows you to meet the requirement for loose coupling better, in my opninion.
How come that the architecture diagram doesn't use the domain layer for ASP.NET?
It seems to me that you may be overarchitecturing your application. Also, while it looks great to support 6 (or so) different front-end technologies, the effort to maintain all of them will be horrendous. I'd stick to one technology for the front-end - most likely HTML5 with client-side MVC or similar.
It makes sense that the WPF, WinForm etc UIs should call the WCF layer. I'm assuming that it's a business requirement to have multiple UIs, otherwise if you can only have one UI a responsive web UI is the most flexible choice.
However, I don't think your MVC UI needs to use the WCF layer. It could call the domain layer directly. That would be faster and remove a pointless layer.
Obviously, that would only work so long as you don't put any logic in your WCF layer. And the WCF layer really shouldn't have any logic in it.
You also state that you want to place IoC & DI in the Distributed Service Layer. That doesn't make much sense in terms of your MVC UI. You'll need to use DI in the MVC project so you can unit test the controllers.
Looking at your diagram I have a couple of points I'm not clear on:
Where is the domain model? Domain Core or the 'model' in the persistence layer?
How does the domain layer interact with the data access layer? The interaction is not as clear as between the service/application layer and domain layer.
What the difference between a repository in the domain layer and a repository in the data access layer? I usually make the distinction of having 'model repositories' in the domain layer which act upon domain model objects, and 'data gateways' in the data access layer which act upon DTO's.
What is domain core? Is this the implementation of the application layer transactions?
Does there need to be a further abstraction of the persistence framework? (EF)
I need to evaluate SOA architecture between WCF Data Services vs WCF RIA Services. Following are some of my parameters:
Multiple Client (HTML5/iOS/Android/Windows 8 Metro/Windows Phone 7)
Disconnected and offline operation
Validation engine
Performance
Network data compression
Support for Cloud Environment
Could anyone help me to gather some data for my evaluation. Also, is there any other good option available for SOA implementation.
I am aware of DevForce.
I'm intimately familiar with RIA Services and know where it falls short. I know little about data services and DevForce, but I know that DevForces advertises to be better than RIA Services in exactly those areas where it annoys me, which is:
RIA can't do group-by or joins of any sort. (Interestingly, the DevExpress toolkit can
do some trickery to group on a RIA Services source in some cases.)
It does understand relationships, but not of the many-to-many kind where it would have to
handle a translation to a bridge table transparently. (EDIT: this is planned for Open Ria Services)
The change tracking works through a context (unit of work) which can only be submitted or
rejected as a whole (out-of-the-box anyway). That usually leads to an application with
many contexts and weird copy operations to transfer entities. The RIAServicesContrib
project helps with that.
It appears to be no longer maintained. I base this on the fact that when Entity Framework 4.1 released their new DbContext API (for code first), Microsoft released a compatibility library with which you could use RIA and EF code first. That library has a version lock on EF 4.1 though, and Microsoft now just states that RIA Services doesn't support DbContext in the form of an Orwellian note to Visual Studio 2012. (EDIT: DbContext is now supported again - EF is currently supported up to version 5, with 6 being likely only supported in Open Ria Services)
Some tasks such as observing changes of related entities programatically (rather than
through data binding) are hard.
Some things which should be really simple, such as getting the context from an attached
entity, are hard.
All queries are single requests, only the remaining CUD (of the CRUD) is batched.
Custom methods to invoke along with normal CUD operations are very limited. In
particular, it's not
possible to cancel one that is scheduled without cancelling the whole context. That has
made them almost useless in most cases where I wanted to use them.
You will have to decide whether or not to use the DomainDataSource, which is a beast
that does too much and too little. You can fetch everything programatically too, but
some things are really quick to wire up with this xaml helper.
There is no built-in support for serializing entities to isolated storage.
Silverlight (and Javascript I believe) are the only supported platforms - no WPF.
(EDIT: this is planned for Open Ria Services - in particular, it should be able to serve BreezeJS)
Since Data Services is older (I think), I didn't care to ever look closely at it. I did however recently skim over the feature list of DevForce and I believe that sounds exciting, although I can't say anything about it from experience.
(EDIT: I found a very knowledgeable comparison of RIA Services and WCF by Colin Blair here.)
The architect compares his product to RIA Services here. I covered some of his points, but not all.
Altogether I can say that RIA Services is clearly better than raw WCF, but it's also clear there has to be something better than that. I hope that's DevForce.
Both expose entities via OData, but RIA Services is specifically targeted to:
Silverlight consumption
Poor man's services - they're easier to get up and running with little effort
WCF Data Services are far more powerful and configurable. The biggest difference (IMO) is that RIA services require one host type per entity, whereas WCF Data Services can automatically host an entire content (a type with multiple IQueryable properties).
That said, both implementations are pretty half baked (again IMO only) and not really well thought out or implemented. ...You may be better off with traditional WCF operations hosted with WebGet/WebInvoke attributes...or using the WCF Web API.
I wouldn't go with DevForce only because it mainly really target Silverlight implementations (if I recall correctly). That said, they're package is pretty cool and far more feature complete than RIA or WCF Data Services.
I have an XBap system designed as a 3-layer application. The XBap client consumes the logic through a WCF Service using netTcpBinding.
For easy of databinding and to be able to re use data validation built-in my business objects, I choosed to reference the business objects library from the xBap client instead of generating proxies.
These objects implement no logic other than they own basic data validation. The real business logic is implemented inside my WCF service.
Now I'm facing a big challenge. I need to port the xBap to silverlight, so I need my silverlight app. to consume the same business logic (which is also used by a winforms LOB application).
Some problems that arise:
1) Can't reference the business objects library from the silverlight client application because it's compiled as a regular dll and not a silverlight one.
2) Can't compile it as a silverlight library because I'd loose lots of functionallity and obviously is not a good idea anyway. If in the future a new .net platform arises I have no warranties that the modified (silverlight) dll will work.
I had some hope when I discovered RIAServices. I read somewhere I could implement a service and use any kind of DAL. (I have a custom one) but I found no example showing how to put RIAServices on top of an existing business layer. It's worth to say that we don't use (and we are not planning to) LINQ. Every example I found started using RIAServices and writing the business logic from scratch using LINQ.
RIAServices generates databinding-ready client code, but I feel I would have to change the entire business layer and that would be really expensive.
So, the solution seems to be to keep using WCF, specially now that silverlight 3.0 supports a new binary binding, and to work with proxies instead of the actual business objects.
The problem is that those proxies don't include data validation, property change notification and change tracking, three aspects that my business clasess perform.
RIAServices resolves these and other aspects but it requieres to work with silverlight proyects. WCF (SVCUtil.exe) generates proxies but they are not 'complete' for our needs. So It seems I'll have to develop my own utility for generating those proxies taking a business object as input.
Before I start doing so, I wish to know if anyone has already faced this problem and was able to resolve it in a convinient and painless way.
Thanks in advance,
Gonzalo
Check this blog post and sample - Business Apps Example for Silverlight 3 RTM and .NET RIA Services July Update: Part 8: WCF Based Data Source.
It shows writing a DomainService using .NET RIA Services that exposes operations and a model to Silverlight client, and in turn works against a WCF service.
You shouldn't need to change your business logic. The DomainService as a layer would reuse that, and it would make sense if you can't expose your business logic/WCF services as-is to Silverlight clients ...
Hope that helps.
In my SOA architecture, I have several WCF services.
All of my services need to access the database.
Should I create a specialized WCF service in charge of all the database access ?
Or is it ok if each of my services have their own database access ?
In one version, I have just one Entity layer instanced in one service, and all the other services depend on this service.
In the other one the Entity layer is duplicated in each of my services.
The main drawback of the first version is the coupling induced.
The drawback of the other version is the layer duplication, and maybe SOA bad practice ?
So, what do so think good people of Stack Overflow ?
Just my personal opinion, if you create a service for all database access then multiple services depend on ONE service which sort of defeats the point of SOA (i.e. Services are autonomous), as you have articulated. When you talk of layer duplication, if each service has its own data to deal with, is it really duplication. I realize that you probably have the same means of interacting with your relational databases or back from the OOA days you had a common class library that encapsulated data access for you. This is one of those things I struggle with myself, but I see no problem in each service having its own data layer. In fact, in Michele Bustamante's book (Chapter 1 - Page 8) - she actually depicts this and adds "Services encapsulate business components and data access". If you notice each service has a separate DALC layer. This is a good question.
It sounds as if you have several services but a single database.
If this is correct you do not really have a pure SOA architecture since the services are not independant. (There is nothing wrong with not having a pure SOA architecture, it can often be the correct choice)
Adding an extra WCF layer would just complicate and slow down your solution.
I would recommend that you create a single data access dll which contains all data access and is referenced by each WCF service. That way you do not have any duplication of code. Since you have a single database, any change in the database/datalayer would require a redeployment of all services in any case.
Why not just use a dependency injection framework, and, if they are currently using the same database, then just allow them to share the same code, and if these were in the same project then they would all use the same dll.
That way, later, if you need to put in some code that you don't want the others to share, you can make changes and just create a new DAO layer.
If there is a certain singleton that all will use, then you can just inject that in when you inject in the dao layer.
But, this will require that they use the same DI framework controller.
The real win that SOA brings is that it reduces the number of linkages between applications.
In the past I've worked with organizations who have done it a many different ways. Some data layers are integrated, and some are abstracted.
The way I've seen it most successfully done is when you create generic data-layer services for each app/database and you create the higher level services based on your newly created data layer.