WCF service contracts designs

Question

In a business application, ideas are dynamics and daily exponential growth. and there isn't such a service contract fit all requiremens neither do with many contracts . let says we ended up 100 000 of contracts which they are ended up 100 000 end points.

is there anyone come accross these kinds of problem which they are limited by WCF? or WCF isn't for an real business application but rather a integration to a business application and exposed a fraction of data exchange?

Could someone kindly show some thoughts?

Regards

Thanks Chris,

I found it is hard to believe as well , 100K tables are fictious but nearly 2000 tables are normal.

let say an application with 100K tables, for each service contract, it needs to receive or return a serializable object which it is a table entity in this case. that means 100K tables would end up 100K service contracts of less and each has some basic implementation such as findby primary key, query methods which returns some sort of array or list and a write method for update/insert.

on top of a table, we would have many business logic method . eg SalesOrderTable would also have methods such as create from qoute, available to promise, total, discount, tax...etc

how would you have a service contract which can provide such information to client side without many contract interfaces/end points?

Answer 1

Your question is a bit abstract, so may be better suited to http://programmers.stackexchange.com , however I think there are still some points that would need to be cleared up before it can be really answered.

It's unclear what you mean by this 'WCF isn't for an real business application but rather a integration to a business application'. When combined with some of the comments you've added, it reads a bit like you're suggesting that you have 1:1 mapping between your services + either your database tables, or your classes. It's unclear if the business logic methods, such as 'create from quote' would sit behind a service interface (so the business logic is in the service), or sit in front of the service (ie the business logic is in the client).

You also seem to be worrying about what at the moment appears to be a spurious requirement (100k tables/services), since at the moment you appear to be dealing with 2k tables... It's also unclear where some of your ideas come from, such as the 12 recommended operations per contract (ITradeService in the example you've indicated has 19 operations).

Would WCF be able to scale up to 100k services? Yes, however you are going to have similar problems to those that you would encounter if you were to try to model a system with 100k classes, or 100k tables. You are going to want to partition the data/logic in an appropriate manner so that they can handle the overhead / requirements and so that they are relatively intuitive to use. This would probably mean that you would want to distribute the services across many servers.

However, as I've said in the comments, this would seem like a very odd situation for you to be in. If you need to model 100k services, then either you're trying to expose too much through the services, or you have an exceptionally large domain that you are trying to model.

Generally, I would expect services to be at a higher level of abstraction than the database model. As an example, let's take a typical customer model... the database may consist of tables like:

• Customer – Core customer details, keyed by id
• Address – Represents a postal address
• Customer Address – Maps customer to address, for a given period of time
• Phone Number – Represents a phone number
• Customer Phone Number – Maps a customer to a phone number, for a given period of time, includes type (mobile, home etc)
• Etc....

You could expose each of the tables as a CRUD operation from a service, but this seems like a bad idea. The logic to 'register a customer' may then sit at the client. They would have to create all of the table entries in the correct order to maintain database integrity. An alternative would be to have a 'Customer' service that contained an operation 'RegisterCustomer', which took in a DataContract 'NewCustomerData', which included basic customer details, address details, phone number details etc... Only one operation is required rather than many to achieve the same results and the client interaction is easier and less error prone.

Not a complete answer, but perhaps something to start with... You may also want to take a look at Principles of Service Design: Service Patterns and Anti-Patterns . Whilst it's a bit old, it does cover some useful topics. I'd suggest that at this point, you may need to think a bit more about what it is you're trying to achieve and how you see your model looking before perhaps coming back with more specific questions.