Top 5 razões para implantar VMware com Tegile
Análise Microsoft anunciou novas APIs e kits de desenvolvimento de software móvel para o Office 365 , a sua plataforma de nuvem para e-mail, armazenamento de documentos e colaboração.
Office 365 usa Azure Active Directory (AD) para autenticação, ea empresa está empurrando a idéia de usar isso não só para o Office 365, mas também como uma identidade nuvem corporativa para outros aplicativos e serviços.
Isto dá o single sign-on do usuário para aplicações de negócios, bem como e-mail, e dando a organização de um único ponto de gerenciamento para gerenciamento de usuários. Se um usuário deixa, a conta pode ser desativada uma vez, imediatamente remover o acesso a aplicações em nuvem.
Chegando no Windows 10 é a capacidade de entrar no Windows usando o AD Azure, como uma alternativa para tradicionais PCs associados a um domínio. É provável que seja uma opção popular, especialmente para as pequenas empresas.
A implicação para os desenvolvedores é que eles vão receber pedidos para escrever aplicativos que usam AD Azure para autenticação. Há também uma opção para ligar para serviços do Office 365, como e-mail ou OneDrive para armazenamento de negócios.
No TechEd, em Barcelona, a Microsoft fez três anúncios. Uma delas foi que APIs REST para Office 365 estão agora fora de pré-visualização. Essas APIs cobrir Mail, arquivos (SharePoint / OneDrive para o negócio), Calendário e Contatos.
O segundo anúncio foi de SDKs móveis para Android e iOS.
Em terceiro lugar, se você escrever um aplicativo web do SharePoint Online, agora você pode adicioná-lo a um lançador de app - uma espécie de menu Iniciar on-line no Office 365.
O pano de fundo para o Office 365 APIs é que a Microsoft está usando OData , um padrão aberto Microsoft-patrocinado, por sua APIs REST. OData tem sua própria linguagem de definição de esquema XML, chamado esquema comum Definition Language (CSDL), que descreve a API, da mesma forma que a WSDL (Web Services Description Language) faz para o padrão de serviço da Web SOAP mais velho e agora impopular. Você pode gerar bibliotecas de código para acessar uma API OData analisando as descrições CSDL, e esta é a forma como os do Office 365 SDKs são gerados, como explicado aqui .
A autorização é feita usando OAuth, um padrão aberto também usado pelo Google e outros.
Então como é que essas coisas funcionam? Tenho enroscou com isso antes, no contexto do desenvolvimento de uma aplicação web que usa Azure AD. A Microsoft fez isso fácil, você pode pensar, com um assistente no Visual Studio que configura uma aplicação ASP.NET para usar Azure AD.
Isto funciona, mas descobri que aplicativo gerado pelo assistente da Microsoft não faz nenhuma provisão para consultar grupos AD Azure. Ele só dá acesso a informações básicas sobre o usuário logado. Se você deseja consultar grupos AD Azure (e, normalmente para aplicações de negócios que vai), então você precisa de uma API adicional chamado a API Graph Azure, para o qual você pode escolher entre velhas bibliotecas .NET que estão obsoletos, ou os novos que estão em visualização, nem opção de ser atraente para os desenvolvedores corporativos.
Ou você pode lançar seu próprio código para usar a API REST, que é um pouco complicados. Eu tenho o meu trabalho de aplicação, mas só depois de uma longa viagem através de vários exemplos de código e experimentos.
Lembrei-me disso quando tentar as novas APIs do Office 365. Eu fui para a Introdução página, que direciona para instalar as ferramentas do Office 365 para o Visual Studio 2013. Isto permite uma opção para adicionar um "serviço ligado" a um aplicativo em desenvolvimento. Depois de ter feito isso, você tem que seguir várias etapas, incluindo a criação de uma assinatura Azure com Azure AD vinculada à conta do Office 365 que você deseja alcançar, registrando uma aplicação no Azure AD, obtendo uma ClientID e Redirect URI que você irá incorporar em seu código, e em seguida, adicionar o código ao seu aplicativo para chamar 365 serviços do Office.
O procedimento para iOS e Android é semelhante, exceto que você baixar o SDK móvel para a plataforma de destino e usar o Xcode, Eclipse, ou seu IDE ou editor em vez de Visual Studio favorito. Outra opção é ficar com .NET e usar compilador multi-plataforma de Xamarin alvejar iOS e / ou Android.
Em seguida, eu bati no link Documentação na página de Introdução. Isso leva você a uma referência de API REST, juntamente com um link para um artigo sobre como integrar o Office 365 APIs em projetos do Visual Studio .NET. Esta descreve um processo em três fases:
1. Chame um Discovery Service para obter os parâmetros corretos para suas chamadas de API REST, que pode ser específico para uma determinada instalação.
2. Obter um token de acesso para autorizar o Office 365.
3. Finalmente, escrever código que realmente usa o serviço que você está segmentando, o Outlook ou o SharePoint.
A única maneira de saber como isso funciona é a experimentá-lo, então eu segui uma das trilhas da Microsoft web para encontrar algumas amostras. O padrão OAuth requer uma dança intrincada troca simbólica. Considere, por exemplo, os seis passos para utilizar o Serviço de descoberta . É algo como: solicitar um token de acesso; o usuário é autenticado; AD Azure emite um código de autorização; você usa o código de autorização para solicitar um token de acesso e um token de atualização adicional; você chamar o serviço de descoberta com o token de acesso; então você usa o token de atualização para obter um token de acesso para o recurso Office 365 necessários. Ufa.
Essa complexidade não ficar no caminho, se as bibliotecas adequadas envolvê-la com sucesso, mas muitas vezes isso não é o caso.
via Alimentação (Feed)
Nenhum comentário:
Postar um comentário