Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

WCF Service - Mulitple or One? 1

Status
Not open for further replies.

TallOne

Programmer
May 14, 2004
164
0
0
US
Hi everyone,

I'm not sure if I'm in the correct forum as I did not see a WCF forum. I'm developing web services for a client that will be exposing methods which are all related to our current web application. I need to know if there is any advantages/disadvantages of putting all the interfaces into one service OR use one service per interface? I just think it would be nicer if the client would add a service with a generic name like MyCompanysService which would expose multiple interfaces. Currently, I have it split up into different services. While creating a client web application for simulation/testing, I find it annoying that I have to add and reference different services/names. I'm thinking from a perspective of the programmer that would be consuming these but would also like to take into consideration of any pros/cons of maintanability, performance or anything else. I'm assuming if I combine them, I would basically have one class that inherits about 15 or so interfaces. :) Thanks in advance for any thoughts or suggestions!

TallOne
 
This gets into the design and architecture. not so much the implementation details. I would take a step back and think about the concepts the service(s) are representing. does it make sense to group them together?

For maintainability, it will always be less impact to add code then to change code. This ties into the concept of the Open Closed Principle.

I'm assuming if I combine them, I would basically have one class that inherits about 15 or so interfaces.
there isn't enough information to say whether this is advisable or not. I would red flag this for review though.

Jason Meckley
Programmer

faq855-7190
faq732-7259
 
Thanks for the feedback jmeckley.

Regarding maintainability, agreed. Taking a look at the concepts the services are representing, I would compare it to an order entry system. Currently, I have a service for each area of the application. For example, a service for customers, one for orders, one for users, one for application security, etc., all related to the same application. Would that be enough info for you to offer an opinion? Also, you did not mention anything about performance of the services. Do you think combining them would degrade performance?
 
Performance... why do we get so hung up on this up front :)
first get it working
then clean up the code
then optimize performance*

*this is quantifiable.
1. what is the acceptable/expected execution time
2. what is the actual execution time
3. if actual > acceptable locate the offending code (dotTrace & Ants profiler are very good at this)
4. refactor to improve performance

9 times out of 10 I find the problem is either remote calls (out of .net [# of database calls/file access]) or the volume of data retrieved from a remote source.

For example, a service for customers, one for orders, one for users, one for application security, etc., all related to the same application
these sound like concepts that would be defined in the domain. Not service calls.

If this is an order processing system i would except to see services like
RetrieveCustomer(id)
PlaceOrder(Customer, ProductAndQuantity[])
ShipOrder(Order)
etc.

The Service Facade (WCF as the implementation) will most likely interact with a number of domain concepts.

Security is a different thing altogether. there is the issue of configuring security which in itself has domain concepts. then there is the issue of authorizing a user to perform a given action.

for instance a customer could place an order, but the customer could not ship the order. shipping will fulfill the orders, but they many not have authorization to cancel an order, that would be up to the customer or customer service (on behalf of the customer).

Security would apply to all the service calls, but would be an aspect of the operation, not part of the operation directly.

I would recommend (the software simplest). He has a wealth of knowledge on the subject. When I first started reading his material I had to unlearn most of what I believed to be "the right way" to understand how Udi approached the problem. Once I got past my own assumptions Udi opened a whole new world of concepts which changed how I think about solving the core functionality of an application.

Jason Meckley
Programmer

faq855-7190
faq732-7259
 
Thanks jason. You have provided some important information. I'm still absorbing info from Udi. I think I'm am going to stay the course of the separate services for now. This is a beta product and my vendor is aware of that. If they complain, it's an easy change to make before putting into production. I've been doing a lot of testing today and you pretty much hit the nail on the head with the "volume of data retrieved from the remote source". It looks like I'll need to implement paging on a couple methods. I'll probably end up giving ants a shot....r3dgate sure has come along way. As far as the Service Facade(agreed and previously implemented), I should have been more descriptive in my analogy. All in all, I think I've done a good job in the design and coding. I'm exposing the services to my Vendor this week and am getting a couple butterflies. I've used wcf that was consumed within my own applications, but this is my first exposed across domains. Thanks again and have a star :)
 
Glad I could help.
I'm still absorbing info from Udi.
This isn't small undertaking. He has great insight into translating the business requirements into functioning code and really gets at the heart of understanding user requirements.

If you ever run into problems with WCF check out Agatha. This project grew out of frustrations with WCF.


Jason Meckley
Programmer

faq855-7190
faq732-7259
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top