Remove remote data portal for mobile apps?

Remove remote data portal for mobile apps?

Old forum URL: forums.lhotka.net/forums/t/10332.aspx


RockfordLhotka posted on Sunday, May 01, 2011

As I've worked more with WP7, and as we've worked on version 4.2 with support for Android and iPhone/iPad, I've been thinking more and more that the entire concept of the remote data portal should just not be included in CSLA on these platforms.

There are some reasons for this.

  1. There are technical issues around assembly signing and type parity that make use of the remote data portal problematic (at best)
  2. Because you don't directly control the update process on the mobile device (the marketplace/app store/whatever and the user have a lot of leeway and control), you can't ensure that the client is updated - certainly not in a timely manner, maybe not at all - so keeping the client and server in sync is problematic
  3. Architecturally, it is recommended that an SOA approach be used, where the mobile app uses messages to communicate with a service app - I don't think any credible architect would recommend otherwise

The WP7 implementation of CSLA does have a working remote data portal. I use it for demos. That is cool, but really it is probably a bad practice for me to even do demos like that, because I'd never recommend building a real app that way.

The Android/iOS implementations of CSLA could have a working remote data portal, but it is a little challenging due to platform differences between the client and .NET, and the somewhat unstable nature of (at least the Android) WCF stack on the client.

So, given that it is a bad idea to do n-tier for mobile apps to start with, plus the technical hurdles on Android/iOS, I am seriously considering removing the WcfProxy type from WP7, Android, and iOS versions of CSLA. This would occur in version 4.2.

But before doing this, I wanted to start a discussion to see if anyone on the forum had a strong argument in favor of the remote data portal (or against).

I look forward to any feedback or discussion - thanks!

Miroslav Galajda replied on Monday, May 02, 2011

Hi,

how would you then recommend to build mobile apps architecture?

I haven't yet developed anything for mobile platform but it seems to me that the mobile platforms are so different from building the app and the UI that I would build mobile apps separately from web app or smart client app on desktops and I would share business logic on the server-side, hence SOA approach is appropriate.

But on the other side if it's possible to target directly .NET code to other non-.NET mobile platforms it will be advantage to have WCF proxy of DataPortal.

The first two points, could be solved be strongly versioning DataPortal server side so that every time you update your server part so that it could become incompatible with client side you should publish new endpoint of DataPortal to use only with new client side version of the app. In this way old clients would use the old endpoint with old server-side components. This is standard approach in versioning web services.

Your DataPortal is some kind of SOA, so after that I would keep that WCF proxy and try to solve that problems by some process steps.

Regards,

Mirec

mesh replied on Tuesday, May 03, 2011

I agree with Mirec. Multiple enpoints could solve problem with versioning, I mentioned that in my previous post.

Also, there is question of WP7 Enterprise Marketplace that will be included in Mango update. Marketplace app. submission process may be different for ent. apps...

- The main issue here is if I can sign WP7 assemblies myself, or MSFT is signing all dll-s in xap with his key? So far I can see that VS2010 does not offer the signing tab on Wp7 project.

- What are the potential risks if we have public WCF Data Portal and signed assemblies?

So please, do NOT remove remote data portal from WP7 CSLA  platform if there is any way to deploy secure WP7 app on Marketplace.

RockfordLhotka replied on Tuesday, May 03, 2011

Although VS doesn't support signing of WP7 assemblies, the CSLA 4 assemblies are signed - this is done by manually editing the csproj file to add the key reference.

The problem we face with signing, is that if Microsoft does re-sign each assembly, then the assembly qualified type names on the mobile device can't be the same as on the server. Because the serialization engines (MobileFormatter in this case) use assembly qualified type names to serialize/deserialize the object graphs, the result would be that the data portal request byte stream couldn't be deserialized when it gets to the server...

The solution to that is to write a new serializer that uses the knowledge of the object graph shape available to CSLA on both sides of the wire. I've thought about doing this anyway, because I could be more efficient (in terms of bandwidth) than the Microsoft serializers, or MobileFormatter, which is directly modeled after the Microsoft serializers.

But that won't happen for a while, because I'm on sabbatical this summer.

When you get right down to it, I'm trying to figure out a way to release 4.2 sooner than later, and the n-tier issue simply won't be resolved by the end of May. So I can do:

  1. Release 4.2 as-is, with the remote data portal probably not actually working, but still there
  2. Remove WcfProxy and release 4.2, at least not giving people the idea that it works when it probably doesn't
  3. Wait to release 4.2 until sometime in October

 

ajj3085 replied on Tuesday, May 03, 2011

Well, given the various constraints, i think #2 might be best for now.

However, my interpretation of the signing is that the code is authenticode signed, not the same as the strong name signing done.  I don't believe the two overlap at all (you can authenticode sign an unmanaged application as well).  If that is the case signing is not an issue for WP7. 

The versioning issue is fairly simple to solve; users MUST update to continue to use the service.  It might seem harsh, but there is the same requirement for PSN, and 77 million users seem ok with that requirement (it won't let you sign on to Playstation Network until you've updated your firmware).  I know mobile devices are a bit different, but I think the user not being able to access Wifi for any significant amount of time would be an edge case.  Even in that event, is it likely the user would burn up their data plan using your app which needs to chat with a server to function all that much?

The issues with Mono[Touch|Droid] do seem much more significant though, so maybe dropping support for remote portals there makes more long term sense. 

So that's just my thoughts, having become much more interested in developing an app for Android at somepoint after finally have caved and purchased a smart phone!  I really wanted a WP7 phone, but having only three options to chose from was a bit of a bummer.  I hope more phones implement it soon.

 I'm curious though, why would no one recommend doing a remote dataportal on a phone app, but that's one of the benefits of doing a Silverlight app.  Isn't that basically the same configuration / situtation?

RockfordLhotka replied on Tuesday, May 03, 2011

Andy

 I'm curious though, why would no one recommend doing a remote dataportal on a phone app, but that's one of the benefits of doing a Silverlight app.  Isn't that basically the same configuration / situtation?

I think it is an architectural thing. Because we have less control over a mobile device app than a Silverlight or WPF app (where you can guarantee instant updates via common deployment options), it makes sense to architect a mobile app to be more loosely coupled to the server than with an app where you can mandate instant updates.

The data portal uses serialization that is version sensitive. So you must keep the client and server in sync - including any assembly signing and versioning.

Suppose you put your app out there, then discover a bug that you could fix (or work around) by making a server change. If you are using version-sensitive serialization, you can't just fix your server - the fix requires an update to the client too. That could take weeks as Microsoft or Apple review your code before putting it into the marketplace. Then it could be weeks more before your users all decide to apply the update from the marketplace.

On the other hand, suppose you use a contract/message-based service interface, so your mobile app interacts with your server app using messages that aren't linked directly to your assembly versioning. That allows you to fix or work around this bug on the server without forcing an update to the client - at least not right away.

You can accomplish a similar thing with an n-tier model - you just need to make sure not to update the version number of the assemblies on the server as you apply the patch to fix the bug. That means you need some external versioning scheme, because you can no longer rely on the .NET assembly version numbers to reflect actual releases.

mesh replied on Wednesday, May 04, 2011

RockfordLhotka
  

Suppose you put your app out there, then discover a bug that you could fix (or work around) by making a server change. If you are using version-sensitive serialization, you can't just fix your server - the fix requires an update to the client too. That could take weeks as Microsoft or Apple review your code before putting it into the marketplace. Then it could be weeks more before your users all decide to apply the update from the marketplace.

I can live with that. For now, all I want is to c/p Silverlight solution, change GUI & application logic and to get fully funcional Wp7 solution. I understand that remote data portal is maybe not the best architectural thing for WP7, but it should be on devs to decide that. WP7 app can be excellent extension to some existing Silverlight or WPF application.  I don't want rewriting lots of code only to accomplish that.

tmg4340 replied on Wednesday, May 04, 2011

Well... perhaps you could live with that.  I'm betting others can't, since during that entire time your mobile app doesn't work.  Given how quickly this stuff tends to move, your app may be relegated to the dust bin by the time your update gets into the ecosystem.

I suppose this should be something that's better elaborated on by Rocky, but in my opinion you're not going to get the same kind of "write once, use everywhere" experience with CSLA and WP7.  Yes, you should be able to use your business objects basically the same.  But the architecture around WP7 is just so different from the other UI technologies that I think what you want to do is not going to work.  Look at what you're doing - you're changing the "application logic" as well as the GUI.  Given that the application logic largely resides in your business layer - where your CSLA objects live...  Unless I'm missing something here, you're already making rather major changes to your architecture.  Not to mention that Rocky has noted that the WCF stack vis-a-vis mobile devices is a little finicky...

I believe there's a difference between letting the developers decide how to architect their app, and giving them an option that's likely going to cause them nothing but headaches and problems.  A bad solution is not always preferable to no solution.  So I agree with Andy - get rid of the WCF proxy for WP7.  In case that wasn't obvious already... Smile

- Scott

RockfordLhotka replied on Wednesday, May 04, 2011

The WCF stack on WP7 is the same as SL3, and it works fine. There's really nothing wrong with WcfProxy on WP7, as long as we're correct (and I think we are) that it is the package/manifest that Microsoft signs, not the individual assemblies in the xap file.

The WCF stack on MonoTouch is maybe OK - that's not clear to me yet.

The WCF stack on Mono for Android is, according to the mono team, in an alpha state. That makes it quite iffy.

sergeyb replied on Wednesday, May 04, 2011

In theory, it should be possible to write version agnsotic "MobileFormatter" via an option on the formatter to allow the client and server to set a custom version via a static method on the MobileFormatter.  Then you have options to use portal or write your own communication mechanism.  I just think that such change to MobileFormatter will be useful in WP7 environment.

 

mesh replied on Wednesday, May 04, 2011

The fate of the Mono team/project is unclear after Attachmate laid off an unknown number of Mono developers yesterday.

WP7 is getting SL4 and Private marketplace, so I think that WP7 should be prioritized.

ajj3085 replied on Thursday, May 05, 2011

tmg4340
Well... perhaps you could live with that.  I'm betting others can't, since during that entire time your mobile app doesn't work.  Given how quickly this stuff tends to move, your app may be relegated to the dust bin by the time your update gets into the ecosystem.

I think mesh's point is that taking away the remote dataportal for WP7 forces everyone to go down the SOA route, whereas he'd like to be the one making the choice.  Maybe his app doesn't need to be updated constantly with new features.  Maybe his requirements are such that it is ok to say "you can't use this app until you update."  Think an app that a fulfillment person uses on a tablet in a warehouse, where it really will be always connected.  Before you say "that's nuts!" my company has a similar situtation; we control the hardware our app works with, and it is in a similar environment.

Also note that I only agree with removing the remote portal given the time constraints Rocky is facing at the moment.  Long term I do think WP7 should include a remote dataportal; if I'm writing a business app which is internal and do have control, why do I want the extra expense of going the SOA route when I can use the remote dataportal just like I do for web / rich client apps.

Also, Andriod and iOS are likely different enough that a remote dataportal will not be feasile there in the foreseeable future. So removing it there makes much more sense.

ajj3085 replied on Thursday, May 05, 2011

RockfordLhotka
I think it is an architectural thing. Because we have less control over a mobile device app than a Silverlight or WPF app (where you can guarantee instant updates via common deployment options), it makes sense to architect a mobile app to be more loosely coupled to the server than with an app where you can mandate instant updates.

I know where I work we are exploring / using mobile and tablet devices in what would traditionally be used for inventory control / picking.  In such an environment, forcing updates can be required, and the devices can be expected to always be on wifi.  I'd hate to lose the cost benefit if NOT doing an SOA solution (assuming I get us to csla to begin with :-) )

I do support removing the remote portal for now from WP7, because there is a bit of uncertainty regarding its feasiblity right now, and your upcoming sabatical limits what you can do, but I'd hate to see it go from WP7 long term.  It sounds like it should be gone more long term for iOS and Andriod, given the state of affairs on those platforms, and they seem like they're different enough.

Just thought I should clarify my position a bit.

 

TSF replied on Wednesday, July 02, 2014

This is an old thread, but I'm curious whether it is still relevant today, specifically in the WinRT world within the enterprise where an n-tier (not SOA) approach is used. We're going to be deploying a WinRT app to sales reps running Win 8.1 Pro and will be managing the devices via SCCM. I'm not sure if SCCM gives us the ability to force updates instantly, but surely it is better than the delay when going through the Windows Store.

We are currently making remote DP calls from the client. We also have historically not been good about "proper" versioning (e.g. we've often left the version of our BO assemblies unchanged at 1.0.0.0, even when there are many iterations). Given this, I'm considering the following approach to versioning the DP this enterprise app:

  1. Maintaining two data portals, basically an A and a B portal.
  2. When an update is made to the app that involves changes to the business assemblies, the remote DP address on the client update will be changed to point to the second DP. For example, from https://app.A.mycompany.com to https://app.B.mycompany.com).
  3. This way, any clients that don't get the update right away will not necessarily break.

Thoughts on this approach?
Tim

RockfordLhotka replied on Wednesday, July 09, 2014

From a CSLA implementation perspective the remote data portal remains 100% intact and is available across all platforms.

The WcfProxy-host is available everywhere except the new Windows Phone 8.1 WinRT environment.

The new HttpProxy-host is available everywhere.

In terms of versioning the data portal to match client versions over time, the "best practice" rules are pretty much the same as with any other service endpoint. This is to say that it is best to embed the version in the URL of the endpoint, and point new versions of the client apps to point to newer versions of the endpoint.

NOTE that this isn't necessary if you control the rollout of the client and can sync that rollout with your server upgrade. Most internal business apps written in Windows Forms, WPF, Silverlight, ASP.NET, etc. fall into this category. But when you add in complex side-loading, or even worse a public store (Apple/Google/Microsoft) then you _must_ assume some clients will run different versions at the same time...

By generalizing the solution to the idea that each client version points to an appropriate server URL for the endpoint avoids any limitations on A/B as you propose.

Suppose you are halfway through rolling out v2 (from v1) and you are a couple weeks into the rollout - perhaps waiting for Apple to approve the iOS app while all the others are already online.

Then suppose you find a bug in v2 and fix it (now v3) just as the v2 iOS app is rolling out. At that point, for a few hours/days you could end up with v1/v2/v3 all being active at some level.

Best to generalize the problem by saying that each client version corresponds to a server endpoint with a versioned URL.

lewischris replied on Thursday, May 05, 2011

Hi Rocky,

Regarding your original question. I agree entirely with points 2 and 3 and they apply very much to our situation - one that I haven't seen mentioned or discussed in any great detail on the CSLA forums - as far as I have been able to see. I find this odd because I imagine our situation would be quite common...

We deploy WinForms and more recently WPF smart client apps to remote client sites. These client sites span hundeds of individual customers who in turn run all flavours of Windows with all manner of different security policies and platforms. Our apps are installed using good old-fashioned .msi/Installshield packages. We have little control or say over how or when our deployed apps get updated - indeed if they ever get updated provided they function correctly and do the job. We have versions of client code that are months and even (in a small number of cases) years behind the 'current' version and they all talk to the same server endpoints! We cannot use ClickOnce and avoid Silverlight because many of our clients' desktop environments do not permit use of these technologies - it is generally the responsibility of the 'IT Department' (not end users) to download and install apps.

Many of our apps still use asmx webservices and WSE (with a custom username/password authentication policy) over https to communicate with our servers. We are migrating to WCF now, but the bottom line is that - for all of our apps and not just 'mobile' apps - we use an SOA architecture where the client ane server are entirely separate applications and communicate across a trust boundary. This is to ensure that all working versions of client apps can continue to communicate with server-side services as they evolve over time.

I would not consider an n-tier client/server architecture for our client apps, so I do find the concept of the Data Portal for SOA apps a little convoluted and - to be frank - confusing. I have two points:

1. Yes, I would agree that the WcfProxy type should be removed from the mobile app platforms. As you say, you should never build these apps this way so having the WcfProxy in there could prove misleading to the uninitiated (I count myself as among this group!). I should qualify this by saying we have no legacy of client code built this way, so it is easy for me to say this.

2. I have gained a huge amount of knowledge and insight from the CSLA books and videos, and from these forums. My company has wholeheartedly adopted CSLA as our business-tier platform of choice. I do feel, however, that support and information for SOA-oriented mobile and smart client (WPF and WinForms) app architectures could be more explictly documented and much more clear and explicit distinctions drawn between n-tier client server architectures and SOA architectures built on CSLA. You are stressing this exact point in this post, and I srongly agree that this distinction should be made and that future releases, books, etc. should cater much more explicitly for SOA and how to do it 'right' with CSLA. For me this is the book/video I would love to see ;)

Chris

 

Copyright (c) Marimer LLC