Which communication architecture should I use

Question

Hi.  I have a proof of concept for my product.  I must decide whether to use asmx web services, or WCF for data communication.  My product reads inventory data.  It also performs some updates and inserts, but no deletes.  I anticipate that each customer will require the application loaded onto 10-20 workstations.  The transaction load will not be tremendous, but of course inventory data is updated daily.  There are a couple of pitfalls I want to avoid:

1) database environment - cloud based.  Database environment can change from time to time, and expect connection strings to change once, or twice per year.  I wish to avoid hard-coding connection strings into a configuration file.  Perhaps a service can know how to connect to the database without exposure to the app.  Also, each of my prospects house their inventory data in their own database in the cloud.  So the service must be knowledgeable and know which database to ping.  Fortunately, the database structure is the same for each of my prospects.

2) Security - maybe HTTPS?  I cannot rely on my clients to have a secure pipeline to the outside world.  Open to suggestions.

3) Consuming the data - I can tailor my DAL, and write contracts which return XML for serialization.

4) Membership - there is no user system.  The users don't "log in", but need to consider how to limit use of my product, if a customer no longer pays for it. 

So at this point, I wish to write a service which does not require customizing for each prospect.  The throughput is not heavy, but need to secure the endpoints.  So far I am thinking WCF may be the way to go, and wish to follow a service oriented architecture.  This is all new for me.  Please give me your thoughts.  The UI is written in WPF.

Answer 1

Hi Skoge.

 

I face similar design considerations for a massive project my company is undertaking at the moment.

So far my research points to WCF being the outright winner for a multitude of reasons:

• Security
• Performance
• SOA

With regards to the database management, this can be handled at the service level, i would imagine you would need to have a central database which contains the "lookup" information required (e.g. Connection Information, Client Information, Other Configurations).  With the above mentioned configuration database, you could easily change database connections where required.

Security - this can be implemented within the service as well as by means of certificates (SSL).  I would opt for both.  We current use a token based system whereby clients / 3rd parties log in to our service and obtain a token which is passed along each subsequent method call.  We perform lightweight but effective validations against the token.

Consuming the data would essentially be the same as you would a web service (i.e. ASMX) however strongly typed objects are preferred and recommended in most cases.

The membership aspect can be incorporated into the configuration database I've eluded to above as can the token based security. Membership can be as simple as a customer / user table or as complex as you require it (i.e. limitations on individual methods as well as data).

In relation to the customization, this depends on your requirements.  This normal forms part of the scoping whereby you will have to determine what to include and what you won't cater for.

Hope the points above help.

Let me know if you wish to discuss the above further.

Answer 2

Kreagan:  where can I read more information regarding the security tokens you mentioned?  If you can point to the MSDN articles, that would be great.