In my role, part of my job is to look into my crystal ball and try to strategically plot a course that will keep us successful today, but also keep us successful tomorrow.
Before looking at the future of portals, I like to remind myself what a portal actually is This quote from Wikipedia, I feel, is a nice short summary SharePoint Portal landing page: Announcement Web Part, Weather, Traffic, Stock Ticker web parts, Enterprise Social (Yammer) newsfeed, Rotating News Banner, etc. Many different data sources, present in a uniform way Whats changing?
This is the reason why we are even talking today Huge trend that is changing the way we are consuming information But there is problem, besides the obvious ones, that we aren’t talking about much
Can’t lump together all portable devices into a single category Need to consider each platform individually Easier to just say mobile as a catch all use Responsive design to handle everything
Apps are king People overwhelming prefer spending time in Apps vs the Browser on their mobile device Not to mention screen size. If no one has over 20% market share that‘s a lot of screens to consider and a lot of use cases. If we need to build apps, how are we going to support all these different platforms without writing the same application a million times in slightly different ways…no one is going to pay for that
Lets review how we currently build SharePoint Solutions
Typically we’ve always built our SharePoint solutions following the multi-tier architecture of SharePoint. We load our code into the GAC and run it in the SharePoint context. The only way to access the data is through the SharePoint presentation layer. Very successful model for the last 10+ years How do you expose this to a mobile device without using responsive design?
While the current way has been successful, it will not be very soon. That approach only works with on prem solutions, does not support Cloud That approach does not work with SharePoint Apps This approach has limited ability to support multiple platforms, responsive design being the best option
Move all SharePoint Code off of the SharePoint Server Service API that allows any device to leverage your business logic Service API can consume more than just SharePoint data and orchestrate the response based on business needs Each consuming application can render data however they seem fit Benefits: Application (Business Logic) Code Base that can be leveraged by any platform Cloud Ready, can be used with either SP on prem or O365 Upgrade are easier as SharePoint is still OOTB SharePoint never has to be exposed to the outside world
What do we need to build it?
This layer needs to be robust to handle any OS on any platform, sounds like the whole goal of SOA The one thing that Web Parts, App Parts, Web Pages and any Mobile device (regardless of platform) have in common is the ability to send and receive HTTP messages. This is why we leverage Web Services to build the services layer…but what kind?
You don’t have to build the same application over and over again, you can leverage SOA to build a single application that each platform can consume in their own way. Goal: Provide a set of services (API) that any platform can leverage regardless of technology
Supports both JSON and XML Client only needs to be able to send and receive HTTP messages
Application Code consists of two pieces: .NET and the Client Object Model The application code is hosting the business logic, it’s the brains of the operation Single application code layer could multiple service layers Not trying to integrate data source into SharePoint, simply pulling data and massaging before sending back to client. Data never needs to live within SharePoint
Here is where things get tricky Security teams look at Mobile Platforms as huge security holes TSX wouldn’t put in a wireless network because someone might sit outside, by the elevators and hack into their network on the wireless signal… Security teams are paid to be paranoid, your job is ensure what they are pushing back on are likely scenarios, remember nothing is 100% secure
Current approach to SharePoint Solutions Back to back Perimeter network model (from MS) WFE server must be in DMZ (externally exposed) One way trust (at least) required between corporate network and DMZ network SharePoint is not a three tier architecture, it’s n-tier. This means the WFE talks directly to the DB means more holes in the corporate firewall How do you control downloaded documents and cached content on the end users device?
SharePoint stays completely inside the corporate network No trust required between DMZ network and Corporate network No additional firewall ports need to be opened aside from the standard HTTP ports (80, 443) Native Apps give you more control over what is stored locally.
Custom HTTP Headers, requires attacker to have inside knowledge IF code is written properly, there is no ability to modify data using only GET requests
Responsive Design, you are unsure what they have downloaded or opened on their mobile device, not stored encrypted and could be opened by anymore that has access to the device No external access to anything? Employees are probably carrying around paper copies, how do you track that? Security is paid to be paranoid, you are paid to be realistic
This SOA layer sounds like a lot of extra work and I’m not sure we have the buy in to build anything this robust Lets see what this look like in a real life example. Lets pretend you are in the oil and gas industry, rare for this city Lets pretend you have a portal that contains a web part that shows you all of your well locations On a standard web page viewed on a PC/Laptop this web part would just be a big map with a bunch of dots on it If it was really sophisticated it may pull the area you work in and target the map to that location by default But how would it work on a tablet? On a phone? Do you really want to pinch and zoom, change the location, etc, just to see the map? Wouldn’t it be cool if the map was targeted to your exact location when on a mobile device? Wouldn’t it be cool if could take your exact location and give you directions on who to get to the well you are interested in? Wouldn’t it be cool if it knew you were at a well location and automatically pulled up the well data for you?
Not much different than how you would currently build today Easy to integrate external data sources, like your PI data Service Layer can be used to combine or massage data from multiple data sources Reusability, many services within the service layer can leverage the same Application code. In general most SharePoint custom pieces are querying a list or library to bring back some data. That can be abstracted into a single call in the application layer
Building multiplatform share point solutions
How to support on-prem, in the cloud and any
2 | SharePoint Saturday Calgary – 31 MAY 2014
12 | SharePoint Saturday Calgary – 31 MAY 2014
SharePoint Server Object Model
SharePoint Client Object Model
Other Data Sources,
14 | SharePoint Saturday Calgary – 31 MAY 2014
15 | SharePoint Saturday Calgary – 31 MAY 2014
What is SOA?
16 | SharePoint Saturday Calgary – 31 MAY 2014
REST Web Services