WCF and N-tier architecture

Question

User1802860499 posted

Hi,,,

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

Answer 1

User-525215917 posted

SOA means Service Oriented Architecture. Your applications are using services not direct data from database. Service provides you with public interfaces of operations and you can call those operations without knowing their exact details. It follows that service can contain also business logic but it is really up to you where you implement your business logic.

If you can use presentation layer -> WCF -> BLL ->DAL it is okay as you can write more apps that share same business logic without duplicating business logic to each application. If you have complex data store then model presented by you may be also in place because you want to serve results to applications and keep applications free from knowledge about constructing the results.

If you have more questions then please feel free to ask :)

Answer 2

User1802860499 posted

Thank you for your response,,,

Currently, I'm using a Dataset and a DataTable to get the data form the stored procedure in the database.
Is that may cause any problem when I use the SOA Concept?

I just need to make sure that my services are created using a format that can be understood by other systems.

Answer 3

User-952121411 posted

Currently, I'm using a Dataset and a DataTable to get the data form the stored procedure in the database.
Is that may cause any problem when I use the SOA Concept?

I just need to make sure that my services are created using a format that can be understood by other systems.

 

I think it really is (2) different questions:

1. Does using the DataSet type break any SOA principals?
2. Is the DataSet type understandable by other systems outside of .NET?

The answer to # 1 is yes and no.  The DataSet is just the type you are deciding to use to communicate data between the client and the service, and if you are implementing a SOA within a domain or controlled environment (i.e. within a corporation) then the DataSet can be considered acceptable.  However, if your SOA design intends to open up to systems wide and broad speaking a universal language, then the outside systems may not understand a DataSet directly.  Here is an interesting blog entry supporting DataSets, but the comments go to speak of how if using a SOA design that DataSets are not advisable:

Datasets vs. Custom Entities:

http://blogs.objectsharp.com/cs/blogs/barry/archive/2004/02/10/273.aspx

The answer to #2 is Yes they could if translated 1st to XML.  A DataSet can be mapped to XML which is a universal language for sharing data between applications.  Since the DataSet's design is based on XML its translation to it is easy.  Take a look to the following for more information:

Writing a DataSet as XML Data:

http://msdn.microsoft.com/en-us/library/zx8h06sz(VS.71).aspx

 

Answer 4

User-525215917 posted

Although it is possible to move dataset between services it is not very nice way to offer meaningful data to service clients. Like atconway mentioned then dataset is returned as XML-string. If you return XML-string instead of list or array of items of type that dataset represents then service clients are in trouble. They have to parse additional XML and detect the types to use based on it. 

Yes, you can use ADO.NET data objects to move data between service and database but don't show these objects in public interface of services. In public interface use your own classes that have meaning in business.

Answer 5

User1802860499 posted

Thanks so much for all  the response