5

I am currently in the planning stages for a fairly comprehensive rewrite of one of our core (commercial) software offerings, and I am looking for a bit of advice.

Our current software is a business management package written in Winforms (originally in .NET 2.0, but has transitioned into 4.0 so far) that communicates directly with a SQL Server backend. There is also a very simple ASP.NET Webforms website that provides some basic functionality for users on the road. Each of our customers has to expose this site (and a couple of existing ASMX web services) to the world in order to make use of it, and we're beginning to outgrow this setup.

As we rewrite this package, we have decided that it would be best if we made the package more accessible from the outside, as well as providing our customers with the option of allowing us to host their data (we haven't decided on a provider) rather than requiring them to host SQL Server, SQL Server Reporting Services, and IIS on the premises.

Right now, our plan is to rewrite the existing Winforms application using WPF, as well as provide a much richer client experience over the web. Going forward, however, our customers have expressed an interest in using tablets, so we're going to need to support iOS and Android native applications as clients, as well.

The combination of our desire to offer off-site hosting (without having to use a VPN architecture) and support clients on platforms that are outside of the .NET ecosystem has led us to the conclusion that all of our client-server communication should take place through our own service rather than using the SQL Server client (since we don't want to expose that to the world and SQL Server drivers do not exist, to my knowledge, for some of those platforms).

Right now, our options as I see them are:

  • Write a completely custom service that uses TCP sockets and write everything (authentication, session management, serialization, etc.) from scratch. This is what I know the most about, but my assumption is that there's something better.
  • Use a WCF service for transport, and either take care of authentication and/or session management myself, or use something like durable services for session management

My basic question is this:

What would be the most appropriate choice of overall architecture, as well as specific features like ASP.NET authentication or Durable Services, to provide a stateful, persistent service to WPF, ASP.NET, iOS, and Android clients?

Adam Robinson
  • 182,639
  • 35
  • 285
  • 343
  • 1
    I'm surprised that you removed WCF tag from your question. Can you explain what you mean by stateful? I have to say that interoperable services for mobile devices are most often developed using REST approach. Durable services were introduced with workflow services to persist running workflow to database. – Ladislav Mrnka May 06 '11 at 17:52
  • As far as WPF is concerned it doesn't really matter what underlying service architecture you use. It is far enough removed from it that you will most likely want to have some sort of Model (and probably ViewModel) layer in between. – Matt West May 06 '11 at 18:01
  • @Ladislav: Just a slip of the finger; I meant to put `WCF`, not `WPF` as the tag. As for stateful, I don't think a *whole* lot will be required. Basically just being able to authenticate the sender and possibly be able to maintain some session information across calls. I don't think it'll be much, but some of what's currently in the client will be on the server (for consistency across platforms), and I want to ensure that we don't hamstring ourselves. – Adam Robinson May 06 '11 at 18:18
  • @Matt: I'm not really concerned about the particulars of WPF at this point as much as I wanted to make it clear that we'll be servicing desktop, web, and mobile. – Adam Robinson May 06 '11 at 18:19

2 Answers2

2

(I am working on the assumption that by "stateful" you mean session-based).

I guess one big question is: Do you want to use SOAP in your messaging stack?

You may be loathe to, as often there is no out-of-box support for SOAP on mobile platforms (see: How to call a web service with Android). No doubt its similarly painful with iOS. Calling SOAP from a browser ("ASP.NET") can't be fun. I'm not even sure its possible!

Unfortunately if you aren't using SOAP, then that quickly rules out most of WCFs standard Bindings. Of the one that remains, "Web HTTP", sessions are not supported because obviously HTTP is a stateless protocol. You can actually add session support by hand using a solution based on Cookies.

You could use the TCP transport (it supports sessions), and build you own channel stack to support a non-SOAP encoding (for example protocol-buffers), but even then you need to be careful because the TCP transport places special 'framing' bytes in it, so that would make interop non-trivial.

What sort of state do you need to store in your sessions? Maybe there are alternative approaches?

Community
  • 1
  • 1
Jack Ukleja
  • 13,061
  • 11
  • 72
  • 113
  • I'm not really pro- or anti-SOAP, but (as you mentioned) interoperability is my main concern with it. Verbosity is also a concern, but if that were the only issue I'd disregard that. As for what I plan on storing in the session, I don't *anticipate* it being much. At this point, I think I could actually be OK with just being able to authenticate the user (meaning, I really *don't* need a session), but some of what is currently on the client will later be on the server, so I'm not entirely sure what I'd need. I was hoping for a long-lived object that represented the session that would just – Adam Robinson May 08 '11 at 20:50
  • (cont.) exist in memory for the duration of the session, but that's just my implementation preference. Obviously, I can emulate this by persisting the information and rehydrating it between calls, but I figured if there was something that offered this already, that would be better. – Adam Robinson May 08 '11 at 20:51
  • If you chose a stateless protocol like HTTP, you will need to do this with cookies. Durable Service might offer you something similar to a session with its instance ID concept, so that might work. – Jack Ukleja May 09 '11 at 01:12
  • I "need" to do this with cookies? Why? If we're talking about a web service whose URL's aren't going to be seen, wouldn't passing a session identifier as GET or POST arguments be just as effective? – Adam Robinson May 09 '11 at 12:39
0

1) consider stateful utility services using singletons, but keep the request/response pattern at the facade level stateless. 2) consider distributed caching, perhaps Windows Server AppFabric Cache.

andrewbadera
  • 1,372
  • 9
  • 19