WCF Service API Design

Question

I am new to WCF . I am designing an ERP system based on WCF/WPF which has the following modules:

a) Estimating
b) Planning
c) Scheduling
d) Accounting
e) Inventory

I have the following questions:

Which instancing mode should I choose? The application will be hosted on a separate executable over an intranet. For each module, there will be around 500-1000 concurrent users connecting to the server. All clients are connected via TCP/IP. The database used is SQL Server.

How do I design my service API? Should I expose a minimal set of standard operations or should I expose large number of functions specific to problem sets? To be more precise, which one of the following do you think is the way to go?

Object[] Get(EntityType type);

void Send(OperationType type, Object[] params);
void Delete(Object[] entities);

----other basic ops and overloads.//based on the parameters, service will //delegate to specific operations

OR

Customer[] GetCustomers();
Job[] GetJobs();

void Updatecustomer(int customerid);
void Updatejob(int jobid);
---//other operations goes here...

I am looking for the trade-offs between these two approaches.

Thanking you all in advance..

Pradeep

This is quite a big and open question, but I would definatly been going for the second approch. If you want to get all the customers from the service, you call for example GetAllCustomers(). I also like to separate for example customers into one small service and jobs into another service. When I am designing services, I like to create microservices. You can read more abot that here http://martinfowler.com/articles/microservices.html — Teis Lindemark, Sep 17 '15 at 06:09
Thank you Teis...Question here...When you use micro services, each service must be authenticated separately...right? — Pradeep, Sep 19 '15 at 13:27

tom redfern · Accepted Answer · 2015-09-17T11:23:26.623

I am designing an ERP system ... which has the following modules...

I think it's really important to think about what you are actually building. To say you are building a single system which does ERP is meaningless. This is where SOA can really be helpful.

What you are actually building:

A service (or services) which satisfies Estimation business use cases via the provision of an Estimation business capability
A service (or services) which satisfies Planning business use cases via the provision of a Planning business capability
A service (or services) which satisfies XXXX business use cases via the provision of a XXXX business capability

I strongly suggest you start building out these individual services as completely separate systems. Each of these services should have

Separate codebase
Separate database (very important!)
Separate deployment mechanism

The key to getting SOA right is being able to compose your services at the appropriate level. It is usual to create a service or multiple services for each business capability you want to support.

Perhaps you only require one service per business capability you have listed, or perhaps you need more than one service, for example, because the Accounting capability is very large and encompases multiple capabilities.

So, lecture over. In the interest of answering your questions:

Which instancing mode should I choose?

For performance you should use per-call. This is the most efficient for high volumes because each call is dispatched to a new service instance which only exists for the duration of the call operation. If you are expecting all clients to be WCF also, then you should be using netTcpBinding.

Should I expose a minimal set of standard operations or should I expose large number of functions specific to problem sets?

This depends on many things. There are no rules here, but one guideline would be that communcation between services within a given business capability can be done via resources and HTTP based operations (GET, POST, etc). This is because within a business capability, it is reasonable to expect an entity or resource exposed by one service to have meaning to a consuming service.

Communication between services in different business domains, however, should be more like the latter example; explicit, business-level operations which have meaning outside of the business domain.

Ultimately your question is a great one, because you could write book answering it. However, for this website, answers need to be kept short so I will stop going on at you. However I strongly recommend reading up on SOA in general, especially about business capabilities, service autonomy, and about the differences between RPC and resource-based web services.

For WCF specifically (if that is the technology you are using), you could research high performance WCF services

WCF Service API Design

1 Answers1