I have worked on quite a few applications utilizing WCF in my career so far. But the way I have used WCF has always been as a means to communicate between the application server and the web server.
I were asked to develop an application to manage employees in an organization, here is how I would do it: I would get the data model in place at the back end, add in tables such as Employee, Department, Roles, Geography, etc. At the middle tier I would put
in business objects such as Employee, Department, Role, Geography, etc., and also code the appropriate business logic classes and methods to handle various operations pertaining to HR, payroll, data entry, and so on. In the WCF service layer at the middle
tier, I would write data contracts such as Employee, Role, Department, Payroll, Geography, etc, then I would add a service contract containing the operation contracts that would interface with the business logic classes and serve out data to the presentation
layer. In effect, the WCF layer serves as a facade to the Business Logic layer. For my presentation layer I would use the WCF proxy as an interface to the business logic, and then provide visual interfaces to end users as a means to perform various operations
that are part of employee management.
Now I am not going to kid anyone, least of all myself, that applications like the one above which I have been developing are equipped with a Service Oriented Architecture (SOA). It doesn't become an SOA just because I am using WCF. What I want my Gurus on
this forum to advise me on is, how would I design, develop and deploy the above application differently to make sure that it is a truly service oriented one. I know there is no single commonly accepted definition of SOA, but I believe all architects can recognize
a true SOA from one that masquerades as one. In particular, if my Gurus can let me know on the following, I would be extremely grateful:
How would the data and service contracts be designed differently?
Instead of merely being a facade to business logic, what else would the WCF layer do?
Would the WCF layer contain more of business logic processing?
Are there any special considerations to be kept in mind while designing and developing the domain classes?
Are the use of any specific technologies/standards recommended to make it more of an SOA?
The above questions only reflect what much I can think of. If my Gurus can offer me more enlightenment, I would indeed be grateful to you!
Just one thing you need to ask yourself: what do you expect to gain from splitting your application into separate tiers, and is it worth the extra effort?
A lot of people use n-tier/WCF/SOA simply because That Is How You Are Supposed To Do It, or for hand-wavy reasons to do with "scalability" or "security." Don't do that: unless you know exactly what you want to get out of it, just stick to a single tier.
Splitting up layers onto separate tiers makes both development and deployment considerably harder and consequently more error-prone.
Just one thing you need to ask yourself: what do you expect to gain from splitting your application into separate tiers, and is it worth the extra effort?
A lot of people use n-tier/WCF/SOA simply because That Is How You Are Supposed To Do It, or for hand-wavy reasons to do with "scalability" or "security." Don't do that: unless you know exactly what you want to get out of it, just stick to a single tier.
Splitting up layers onto separate tiers makes both development and deployment considerably harder and consequently more error-prone.
Guru jammycakes,
Let us leave the question of why n-tier or why SOA for another thread. I am trying to learn how to correctly design and implement an SOA. I am sure you would agree with me wen I say that the mere use of a WCF layer in an application doesn't make it an SOA.
If instead of using .NET and WCF, you would prefer to implement an SOA using COM or WIN32 components, utilizing Windows DNA, DCOM or plain MSMQ messaging, with everything hosted on a single 16 bit machine running Windows 3.1 or Windows 95, please tell me how.
I would indeed be thankful to you! :)
Member
42 Points
102 Posts
How do I develop this application differently, if I were to make it an SOA?
Sep 02, 2015 06:53 AM|Novice Kid|LINK
Gurus!
I have worked on quite a few applications utilizing WCF in my career so far. But the way I have used WCF has always been as a means to communicate between the application server and the web server.
I were asked to develop an application to manage employees in an organization, here is how I would do it: I would get the data model in place at the back end, add in tables such as Employee, Department, Roles, Geography, etc. At the middle tier I would put in business objects such as Employee, Department, Role, Geography, etc., and also code the appropriate business logic classes and methods to handle various operations pertaining to HR, payroll, data entry, and so on. In the WCF service layer at the middle tier, I would write data contracts such as Employee, Role, Department, Payroll, Geography, etc, then I would add a service contract containing the operation contracts that would interface with the business logic classes and serve out data to the presentation layer. In effect, the WCF layer serves as a facade to the Business Logic layer. For my presentation layer I would use the WCF proxy as an interface to the business logic, and then provide visual interfaces to end users as a means to perform various operations that are part of employee management.
Now I am not going to kid anyone, least of all myself, that applications like the one above which I have been developing are equipped with a Service Oriented Architecture (SOA). It doesn't become an SOA just because I am using WCF. What I want my Gurus on this forum to advise me on is, how would I design, develop and deploy the above application differently to make sure that it is a truly service oriented one. I know there is no single commonly accepted definition of SOA, but I believe all architects can recognize a true SOA from one that masquerades as one. In particular, if my Gurus can let me know on the following, I would be extremely grateful:
How would the data and service contracts be designed differently?
Instead of merely being a facade to business logic, what else would the WCF layer do?
Would the WCF layer contain more of business logic processing?
Are there any special considerations to be kept in mind while designing and developing the domain classes?
Are the use of any specific technologies/standards recommended to make it more of an SOA?
The above questions only reflect what much I can think of. If my Gurus can offer me more enlightenment, I would indeed be grateful to you!
Novice Kid
Member
430 Points
399 Posts
Re: How do I develop this application differently, if I were to make it an SOA?
Sep 03, 2015 08:30 AM|jammycakes|LINK
Just one thing you need to ask yourself: what do you expect to gain from splitting your application into separate tiers, and is it worth the extra effort?
A lot of people use n-tier/WCF/SOA simply because That Is How You Are Supposed To Do It, or for hand-wavy reasons to do with "scalability" or "security." Don't do that: unless you know exactly what you want to get out of it, just stick to a single tier. Splitting up layers onto separate tiers makes both development and deployment considerably harder and consequently more error-prone.
Member
42 Points
102 Posts
Re: How do I develop this application differently, if I were to make it an SOA?
Sep 04, 2015 01:32 PM|Novice Kid|LINK
Guru jammycakes,
Let us leave the question of why n-tier or why SOA for another thread. I am trying to learn how to correctly design and implement an SOA. I am sure you would agree with me wen I say that the mere use of a WCF layer in an application doesn't make it an SOA. If instead of using .NET and WCF, you would prefer to implement an SOA using COM or WIN32 components, utilizing Windows DNA, DCOM or plain MSMQ messaging, with everything hosted on a single 16 bit machine running Windows 3.1 or Windows 95, please tell me how. I would indeed be thankful to you! :)
Novice Kid