Préservation de l'état dans Silverlight 3

Question

Je développe une application Silverlight 3 que je souhaite connecter à un service Web avec un fichier .dll fourni ou avec SOAP. Mais le fichier .dll ne convient pas à Silverlight, donc je ne peux pas le faire. Et je ne peux pas accéder au service SOAP en raison de problèmes inter-domaines (je ne l’héberge pas, donc un client xp politique ne fera pas).

Donc, ma solution consiste à inclure le fichier .dll dans un service Web activé par WCF dans mon propre domaine et à laisser l'application Silverlight appeler le service Web. Cela fonctionne.

Maintenant, à mon problème: le client fourni à partir du fichier .dll référencé par mon service Web possède une méthode .Connect (), je dois donc enregistrer l'état de l'objet. Mais puis-je faire ça? Probablement pas parce que Silverlight ne prend pas en charge wsHttpBinding. Je sais que je peux accéder aux variables de session ASP, mais puis-je aussi le faire en dehors du navigateur? Je ne peux trouver qu'une solution à mon problème: enregistrer le nom d'utilisateur / mot de passe dans une session ASP et appeler la méthode .Connect () dans chaque méthode. Mais c’est vraiment une mauvaise solution.

De meilleures idées?

Je ne pense pas avoir été clair et je m'en excuse. Mon anglais est bien la cause principale de cela.

j'ai:

Mon application Silverlight qui s'exécute sur un site Web et en dehors du navigateur

Mon service WCF hébergé dans le même domaine.

Un service Web interdomaine (je ne parviens pas à accéder à un fichier de stratégie interdomaine)

Mon service Web WCF fournit une couche entre mon application et le service Web interdomaine, car vous ne pouvez pas ajouter de services Web interdomaine sans le fichier de stratégie.

Mon service Web se présente comme suit (de manière abstraite):

class MyWebService
{
   CrossDomainWebServiceClient client = new CrossDomainWebServiceClient();

   public void Connect(string username, string password)
   {
      client.Connect(username, password);
   }

   public object Foo()
   {
      //GetEmployees() do only work if I'm connected
      return client.GetEmployees(); 
   }
}

La méthode Foo () ne fonctionne pas car il s'agit d'une session par appel et non d'une session par instance. Je veux que ça marche. Donc, l'objet client doit être préservé pour le prochain appel. Les sessions demandées ne fonctionnent pas dans Silverlight car wsHttpBinding n'est apparemment pas pris en charge.

Answer 1

Je ne suis pas sûr à 100% de comprendre la question, mais je travaille dans une situation assez similaire et voici comment nous y répondons.

1. Service Web tiers qui stocke toutes les données.
2. niveau intermédiaire WCF créé par nous pour gérer tous les interactions avec webservice.
3. niveau client Silverlight qui se connecte à notre service WCF.

Pour l'authentification, nous avons une méthode d'authentification sur notre service WCF qui appelle ensuite le service Web et transmet les informations d'identification que nous avons transmises de Silverlight. Le service Web répond ensuite avec un jeton d'authentification que nous avons défini comme cookie dans la demande Silverlight. Tous les futurs appels de Silverlight incluront donc ce jeton que nous transmettons à chaque appel vers le service Web.

Évidemment, vous ne voudriez pas définir le nom d'utilisateur et le mot de passe comme cookie. Mais espérons que vous puissiez récupérer une sorte de cookie ou de jeton sur le service Web que vous pourrez ensuite utiliser lors de futures demandes.

Réponse mise à jour

En fonction de vos spécifications mises à jour, il semblerait que vous deviez mettre en cache les clients du service. Vous pouvez essayer de vous faire plaisir avec Contextes d'instance WCF personnalisés , mais ici est une approche simple.

[ServiceContract(Namespace = "")]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class ProxyService
{
    private static Dictionary<Guid, DateTime> clients = new Dictionary<Guid, DateTime>();

    public ProxyService()
    {

    }

    [OperationContract]
    public void Login()
    {
        Guid id = Guid.NewGuid();
        // perform your login here
        clients.Add(id, DateTime.Now); // store your client instead of a date
        SetCookie(id);
    }

    [OperationContract]
    public DateTime Foo()
    {
        var id = ReadCookie();
        if (clients.ContainsKey(id))
        {
            return clients[id];
        }
        return DateTime.MinValue;
    }

    private void SetCookie(Guid id)
    {
        var cookie = new HttpCookie("id", id.ToString());
        cookie.Expires = DateTime.Now.AddMinutes(10);
        HttpContext.Current.Response.AppendCookie(cookie);
    }

    private Guid ReadCookie()
    {
        var cookie = HttpContext.Current.Request.Cookies.Get("id");
        if (cookie != null)
        {
            cookie.Expires = DateTime.Now.AddMinutes(10);
            return new Guid(cookie.Value);
        }
        return Guid.Empty;
    }
}

Bien sûr, au lieu d’un DateTime, vous stockeriez votre service client. Maintenant, il y a quelques problèmes avec cette approche qu'il vous reste à résoudre.

1. Délais d'attente - vous auriez besoin d'un moyen de temporiser les sessions qui ne sont pas actives et de les supprimer de la liste des clients.
2. Je ne suis pas sûr que ce soit une façon super sécurisée de faire les choses. Si quelqu'un a votre guide, il peut accéder à vos employés. Cependant, je ne vois pas comment cela se produirait, mais je ne suis pas un expert en sécurité.

C'est tout pour l'instant, si vous avez des questions, laissez-moi savoir.

Answer 2

Si votre dll n’est pas construite avec le runtime silverlight 3, vous ne pouvez pas la référencer depuis votre projet silverlight. Demandez à votre client de reconstruire la DLL dans ce runtime.

Silverlight est strict en ce qui concerne l’exécution de codes nécessitant une confiance totale. Si l'application silverlight ne sait pas dans quel runtime se trouve la dll, elle ne l'acceptera pas et ne l'appellera pas du tout.

Answer 3

Mise à jour:

Vous pouvez marquer votre service pour conserver l'objet de service en mémoire pendant toute la durée de la session.

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
class MyWebService{   
    CrossDomainWebServiceClient client = new CrossDomainWebServiceClient();   

Ceci devrait garder votre client interdomaine initialisé entre les appels.

Réponse originale:

L'objet Silverlight reste actif entre les appels afin que vous puissiez conserver l'état en mémoire.

Si vous souhaitez stocker l'état entre les exécutions de l'application Silverlight, vous pouvez le sérialiser sur un stockage isolé sur l'ordinateur client et le relire au démarrage de l'application Silverlight.