ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

iPhone Developer Summit West

?
?
J
jasonc411

This is the deck I presented on Tues 3-Nov on patterns I am finding in my work in Distributed Mobile applications. Follow my sites for updates(addl patterns and sample code) to this later in the month.

1 of 20
Design Patterns For Distributed Mobile Applications Jason H Christensen Intelligence In Motion Partners, LLC iPhone Developer Summit West, 2009
What We¡¯ll Cover ? Why Distributed Mobile Patterns ? Simple REST Consumer ? Authenticated REST Consumer ? Key Handling Pattern ? XMPP Coordinator Stream Pattern ? Remote Invocation Push Response Pattern
Enterprise Mobile Architectures Timeline
Why Distributed Mobile Architectures Corporateers are leaving their laptops at their desk. iPhone in the Enterprise has made some noise, but Blackberry is entrenched due to existing apps. iPhone has to create key advantages to become more competitive in the enterprise space. iPhone has some key disadvantages, limited carrier options, new programming language, ¡°data walking off¡±
Which Distributed Mobile Architectures Some key areas to target for Mobile Enterprise Applications ? Sales Force/Remote Management ? Sales, Store Mgr, Distribution ? Executive Information Systems ? Dashboard and Alerts ? Workflow Engagement ? Legal, Purchasing, Receiving ? Customer Issue Resolution ? Escalations/Technical Support
Enter Distributed Mobile Patterns The First Five Distributed Mobile Patterns address some hot button current enterprise features: ? Connecting to internal services ? Simple REST Consumer ? Connecting to cloud ? Secure Key Handling Pattern ? Authenticated REST Consumer ? Workflow Integration ? Remote Invocation/Push Response ? XMPP Coordinator Stream Pattern
Simple REST Consumer Pattern Intent To provide a quick and easy mobile REST implementation Motivation: There are numerous requests where we create a proof of concept. The motivation is to keep the client and server as simple as possible to show we can deliver on the crux of a given need. Consequences: Ideal for getting a RESTful system setup quickly, but¡­ ? Does not handle custom headers, or authentication ? Trivial Systems only, Systems that contain sensitive functionality or information should use the ¡°Authenticated REST Consumer¡± pattern.
Simple REST Consumer(iPhone) KeyStrings enum ExpectedTags +kElementName1,¡­ From didStartElement: SimpleRESTCall if(currentElement == kElementName){ -initWithFormattedURL:(NSString*)fUrl currentTag = enumForThatTag; andParameters:(NSDictionary*)params } - parser:didStartElement: - parser:didEndElement: - parser:foundCharacters: - (NSObject*)getData MyRESTCall Concrete Consumer
Authenticated REST Consumer Pattern Intent To provide a common framework for federated identity RESTful services. Motivation: This pattern is used in systems that require manipulation of the ¡°Authorization¡± request header, based on headers. Eg: ? Amazon AWS based invocations, ? OAUTH invocations, and custom implementations Consequences: This is a generalized pattern, most systems use similar methods, but the header combination or method for acquiring the token may differ. To handle this, TokenManager and StringToSign are implementation specific.
Authenticated REST Consumer(iPhone) enum ExpectedTags AuthTokenGenerator - TokenManager* request KeyStrings - StringToSign* signatureString +kElementName1,¡­ -initWithRequest:(NSURLRequest*)fUrl; - (NSString*)getAuthString AuthenticatedRESTCall - NSMutableURLRequest* request - NSHTTPURLResponse* response -AuthTokenGenerator* authTokenGen; -initWithFormattedURL:(NSString*)fUrl TokenManager StringToSign andParameters:(NSDictionary*)params -initWithRequest: - parser:didStartElement: (NSURLRequest*)fURL - parser:didEndElement: - parser:foundCharacters: - (NSObject*)getData AuthSpecific AuthSpecific TokenMgr StringToSign MyAuthenticatedRESTCall
Lightweight Network Status Monitor Intent: Provide a lightweight status mechanism to all applications in a standard fashion Motivation: A mobile application can have a number of connection types, not connected, keeping note of this status allows communication to the user when connectivity changes. Consequences: This is a very simple pattern, and probably could be implemented inline just as easily. The goal of this pattern is the use of a delegate pattern to notify application when statuses change.
Lightweight Network Status Pattern enum ConnectionType LwNetStatusDelegate -notify:(enum ConnectionType) presentType; NetworkStatusMonitor - ConnectionType* ct - NSArray* delegates -checkNetStatusAndTypeFor:(NSString*) net - notifyDelegates AppDelegate
Remote Invocation Push Resopnse Intent To provide notifications from workflow systems to a mobile user Motivation: Needed to provide a workflow step an acknowledgement, response, or notification. Push notification is more resilient for verifications, app can close or be interrupted and the push will still be received. Consequences: There is additional cost and security considerations with this over a traditional email response. Email is a valid alternative, but does not notify the user directly.
Remote Invocation/Push Response (iPhone) iPhone Application sendDeviceToken Web Application initPushFunctions newDeviceListener HTTP Request AuthenticatedRESTAsynch HTTP Response ServerListener QueueRequest ProcessingQueue
Remote Invocation/Push Response (iPhone) iPhone Application Web Application ServerProcess Processing Complete didFinishLaunchingWithOptions sendResponseID pushBinaryResponse didReceiveRemoteNotification HTTP Request AuthenticatedRESTPayload HTTP Response ServerListener
XMPP Coordinator Stream Pattern Intent Utilize a standard messaging protocol as a baseline for higher level messaging functionality Motivation: This was kind of a eureka moment, but we were stuck trying to find a way to bridge between J2EE based MOM and our Mobile Apps. We decided to create a listener on the XMPP port and to use that to bridge with the phone. Consequences: There is additional cost and security considerations with this over a traditional email response. Email is a valued alternative, but does not notify the user directly.
XMPP Coordinator Stream Pattern iPhone XMPP presence: Application show Server initXMPP xmppListener group invite xmppListener Group::init rsrc1@coordsvr Group:<coordid> Activity::Enlist CoordMsg xmppListener Activity::Perform CheckStatus xmppListener Activity::Complete Close xmppListener
XMPP Coordinator Notes ? Each resource enlists on it¡¯s own ? We create a group for a set of resources ? Messages and responses are sent to the group ? Any phase can fail causing a compelete failure ? Since group, all failures are seen by each resource
Distributed Mobile Design Patterns ? What we covered: ? Enterprise Mobile History ? What spaces are hot for enterprise mobile ? Five patterns for Mobile App enablement ? XMPP Coordinator Stream ? Remote Invocation/Push Response ? Lightweight Network Status ? Authenticated REST Requests ? Simple REST Request
Questions? ? Feel free to contact me: Jason H Christensen jason_h_christensen@jasonc411.com ºÝºÝߣshare: jasonc411 Twitter: jasonc411 http://jasonc411.com

More Related Content

iPhone Developer Summit West

  • 1. Design Patterns For Distributed Mobile Applications Jason H Christensen Intelligence In Motion Partners, LLC iPhone Developer Summit West, 2009
  • 2. What We¡¯ll Cover ? Why Distributed Mobile Patterns ? Simple REST Consumer ? Authenticated REST Consumer ? Key Handling Pattern ? XMPP Coordinator Stream Pattern ? Remote Invocation Push Response Pattern
  • 4. Why Distributed Mobile Architectures Corporateers are leaving their laptops at their desk. iPhone in the Enterprise has made some noise, but Blackberry is entrenched due to existing apps. iPhone has to create key advantages to become more competitive in the enterprise space. iPhone has some key disadvantages, limited carrier options, new programming language, ¡°data walking off¡±
  • 5. Which Distributed Mobile Architectures Some key areas to target for Mobile Enterprise Applications ? Sales Force/Remote Management ? Sales, Store Mgr, Distribution ? Executive Information Systems ? Dashboard and Alerts ? Workflow Engagement ? Legal, Purchasing, Receiving ? Customer Issue Resolution ? Escalations/Technical Support
  • 6. Enter Distributed Mobile Patterns The First Five Distributed Mobile Patterns address some hot button current enterprise features: ? Connecting to internal services ? Simple REST Consumer ? Connecting to cloud ? Secure Key Handling Pattern ? Authenticated REST Consumer ? Workflow Integration ? Remote Invocation/Push Response ? XMPP Coordinator Stream Pattern
  • 7. Simple REST Consumer Pattern Intent To provide a quick and easy mobile REST implementation Motivation: There are numerous requests where we create a proof of concept. The motivation is to keep the client and server as simple as possible to show we can deliver on the crux of a given need. Consequences: Ideal for getting a RESTful system setup quickly, but¡­ ? Does not handle custom headers, or authentication ? Trivial Systems only, Systems that contain sensitive functionality or information should use the ¡°Authenticated REST Consumer¡± pattern.
  • 8. Simple REST Consumer(iPhone) KeyStrings enum ExpectedTags +kElementName1,¡­ From didStartElement: SimpleRESTCall if(currentElement == kElementName){ -initWithFormattedURL:(NSString*)fUrl currentTag = enumForThatTag; andParameters:(NSDictionary*)params } - parser:didStartElement: - parser:didEndElement: - parser:foundCharacters: - (NSObject*)getData MyRESTCall Concrete Consumer
  • 9. Authenticated REST Consumer Pattern Intent To provide a common framework for federated identity RESTful services. Motivation: This pattern is used in systems that require manipulation of the ¡°Authorization¡± request header, based on headers. Eg: ? Amazon AWS based invocations, ? OAUTH invocations, and custom implementations Consequences: This is a generalized pattern, most systems use similar methods, but the header combination or method for acquiring the token may differ. To handle this, TokenManager and StringToSign are implementation specific.
  • 10. Authenticated REST Consumer(iPhone) enum ExpectedTags AuthTokenGenerator - TokenManager* request KeyStrings - StringToSign* signatureString +kElementName1,¡­ -initWithRequest:(NSURLRequest*)fUrl; - (NSString*)getAuthString AuthenticatedRESTCall - NSMutableURLRequest* request - NSHTTPURLResponse* response -AuthTokenGenerator* authTokenGen; -initWithFormattedURL:(NSString*)fUrl TokenManager StringToSign andParameters:(NSDictionary*)params -initWithRequest: - parser:didStartElement: (NSURLRequest*)fURL - parser:didEndElement: - parser:foundCharacters: - (NSObject*)getData AuthSpecific AuthSpecific TokenMgr StringToSign MyAuthenticatedRESTCall
  • 11. Lightweight Network Status Monitor Intent: Provide a lightweight status mechanism to all applications in a standard fashion Motivation: A mobile application can have a number of connection types, not connected, keeping note of this status allows communication to the user when connectivity changes. Consequences: This is a very simple pattern, and probably could be implemented inline just as easily. The goal of this pattern is the use of a delegate pattern to notify application when statuses change.
  • 12. Lightweight Network Status Pattern enum ConnectionType LwNetStatusDelegate -notify:(enum ConnectionType) presentType; NetworkStatusMonitor - ConnectionType* ct - NSArray* delegates -checkNetStatusAndTypeFor:(NSString*) net - notifyDelegates AppDelegate
  • 13. Remote Invocation Push Resopnse Intent To provide notifications from workflow systems to a mobile user Motivation: Needed to provide a workflow step an acknowledgement, response, or notification. Push notification is more resilient for verifications, app can close or be interrupted and the push will still be received. Consequences: There is additional cost and security considerations with this over a traditional email response. Email is a valid alternative, but does not notify the user directly.
  • 14. Remote Invocation/Push Response (iPhone) iPhone Application sendDeviceToken Web Application initPushFunctions newDeviceListener HTTP Request AuthenticatedRESTAsynch HTTP Response ServerListener QueueRequest ProcessingQueue
  • 15. Remote Invocation/Push Response (iPhone) iPhone Application Web Application ServerProcess Processing Complete didFinishLaunchingWithOptions sendResponseID pushBinaryResponse didReceiveRemoteNotification HTTP Request AuthenticatedRESTPayload HTTP Response ServerListener
  • 16. XMPP Coordinator Stream Pattern Intent Utilize a standard messaging protocol as a baseline for higher level messaging functionality Motivation: This was kind of a eureka moment, but we were stuck trying to find a way to bridge between J2EE based MOM and our Mobile Apps. We decided to create a listener on the XMPP port and to use that to bridge with the phone. Consequences: There is additional cost and security considerations with this over a traditional email response. Email is a valued alternative, but does not notify the user directly.
  • 17. XMPP Coordinator Stream Pattern iPhone XMPP presence: Application show Server initXMPP xmppListener group invite xmppListener Group::init rsrc1@coordsvr Group:<coordid> Activity::Enlist CoordMsg xmppListener Activity::Perform CheckStatus xmppListener Activity::Complete Close xmppListener
  • 18. XMPP Coordinator Notes ? Each resource enlists on it¡¯s own ? We create a group for a set of resources ? Messages and responses are sent to the group ? Any phase can fail causing a compelete failure ? Since group, all failures are seen by each resource
  • 19. Distributed Mobile Design Patterns ? What we covered: ? Enterprise Mobile History ? What spaces are hot for enterprise mobile ? Five patterns for Mobile App enablement ? XMPP Coordinator Stream ? Remote Invocation/Push Response ? Lightweight Network Status ? Authenticated REST Requests ? Simple REST Request
  • 20. Questions? ? Feel free to contact me: Jason H Christensen jason_h_christensen@jasonc411.com ºÝºÝߣshare: jasonc411 Twitter: jasonc411 http://jasonc411.com