Forenbeiträge von Bastor

Fragen, Diskussion, Kritik zu Projekt ".NET Applikationsserver"

B

16.06.2010 - 15:54 Uhr

Hallo Rainbird,

ich habe versucht meine Solution soweit zu ordnen und entsprechend deinen Vorschlägen zu modelieren - habe mich aber auch durch deinen MSDN Link gelesen.

Hab jetzt ein, zwei Zusammenhänge mehr in deiner Applikation verstanden 😃

Ich verstehe aber noch nicht ganz den Nutzen einer Interface Klasse?
Soweit ich das verstanden habe, wird diese als Proxy Stellvertreter Objekt der Remoting Instanz genutzt. Aber wozu dient das ganze? Wieso nicht direkt die Manager Klasse, statt dem Interface ?

Mein Appserver sieht jetzt folgendermaßen aus:


    public partial class Appserver : Form
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.Run(new Appserver());
        }

        public Appserver()
        {
            InitializeComponent();
            this.list_Hist.Items.Add(DateTime.Now.ToShortTimeString() + " " + "Initialisiere ...");
        }

        private void ListWellKnownServiceTypes()
        {
            try
            {
                foreach (WellKnownServiceTypeEntry entry in RemotingConfiguration.GetRegisteredWellKnownServiceTypes())
                {
                    this.list_Hist.Items.Add(DateTime.Now.ToShortTimeString() + " " + entry.TypeName + " is available at " + entry.ObjectUri);
                }
            }
            catch (Exception ex)
            {
                string txt = "Eventuell liegt die Konfigurationsdatei in einem falschen Format vor." + Environment.NewLine +
                     "Genaue Fehler Informationen:" + Environment.NewLine + Environment.NewLine +
                "  Nachricht: " + ex.Message + Environment.NewLine +
                "  Quelle: " + ex.Source + Environment.NewLine + Environment.NewLine +
                "  Stack Trace:" + Environment.NewLine +
                ex.StackTrace;
                MessageBox.Show(txt, "Generic Exception", MessageBoxButtons.OK, MessageBoxIcon.Stop);
            }
        }

        private void Appserver_Load(object sender, EventArgs e)
        {
            // Daten über die ausführende Assembly abrufen
            Assembly currentAssembly = Assembly.GetExecutingAssembly();


            try
            {
                this.list_Hist.Items.Add(DateTime.Now.ToShortTimeString() + " " + "Try to load Remoting Configuration File ...");

                // Pfad zur Konfigurationsdatei erzeugen
                string configFile = currentAssembly.Location + ".config";
                if (File.Exists(configFile))
                {
                    // Remoting-Infrastruktur konfigurieren
                    RemotingConfiguration.Configure(configFile, true);
                    this.list_Hist.Items.Add(DateTime.Now.ToShortTimeString() + " " + "Remoting Configuration loading complete.");
                }



                this.list_Hist.Items.Add(DateTime.Now.ToShortTimeString() + " " + "Try to load Business Services ...");
                ListWellKnownServiceTypes();
            }
            catch (Exception ex)
            {
                // FileNotFound ?

                // Will catch any generic exception
                string txt;
                txt = "Konfiguration der App.config Datei fehlgeschlagen, oder es liegt ein falsches Format vor." + Environment.NewLine +
                "Stellen Sie sicher das die App.config Datei im selben Verzeichnis wie die Anwendung liegt " +
                " und die Datei im richtigen Format vorliegt." + Environment.NewLine +
                "Nutzen Sie das Hilfe Menü, About um herauszufinden wo die exe Datei liegt." + Environment.NewLine + Environment.NewLine +
                "Genaue Fehler Informationen:" + Environment.NewLine + Environment.NewLine +
                "  Nachricht: " + ex.Message + Environment.NewLine +
                "  Quelle: " + ex.Source + Environment.NewLine + Environment.NewLine +
                "  Stack Trace:" + Environment.NewLine +
                ex.StackTrace;
                MessageBox.Show(txt, "Generic Exception", MessageBoxButtons.OK, MessageBoxIcon.Stop);

                this.list_Hist.Items.Add(DateTime.Now.ToShortTimeString() + " " + "Remoting Configuration File loading failed.");
            }
        }

    }

Die App.config sieht folgendermaßen aus:


<configuration>
<system.runtime.remoting>
	<application>
		<service>
			<wellknown
				mode="Singleton"
				type="CTI_Integration.Extension.Services.CallManager, CTI_Integration.Extension.Services"
				objectUri="CTI_Integration.Extension.Contracts.ICallManager"
		/>
		</service>
		<channels>
			<channel ref="tcp" port="9090">
				<serverProviders>
					<formatter ref="binary"/>
				</serverProviders>
			</channel>
		</channels>
	</application>
</system.runtime.remoting>
</configuration>

Ich habe zusätzlich noch eine AppServer.API (wie du) - welche allerdings nur das Call.cs Klassen Objekt beherbergt (was ich momentan etwas überflüssig finde) - du verwendest die API um Server Funktionen zu integrieren und anzusprechen, allerdings soll mein AppServer lediglich die Call Klassen Objekte verwalten.

Macht eine AppServer API bei mir sinn?

Meine Call Klasse sieht wie folgt aus:


using System;
using System.Data;
using System.Collections.Generic;
using System.Text;
using System.Diagnostics;
using System.Xml.Serialization;

namespace CTI_Integration.AppServer.API
{
    /// <summary>
    /// Beschreibt ein Call Object auf dem Application Server
    /// </summary>
    [Serializable]
    [XmlRoot(ElementName="Call")]
    public class Call
    {
        #region Deklarationen

        // Universal Call ID 1
        [XmlElement(ElementName = "UCID_1", IsNullable = false)]
        string _ucid_1 = string.Empty;
        
        bla bla bla ... 
   
        #endregion

        #region Konstruktor

        /// <summary>
        /// Konstruktor
        /// </summary>
        public Call()
        {
            // Default Konstruktor
        }
      
        Bla bla bla

        #endregion

        #region Eigenschaften

        /// <summary>
        /// Gibt die Universal Call ID zurück oder setzt sie  
        /// </summary>
        public string UCID_1
        {
            get { return _ucid_1; }
            set { _ucid_1 = value; }
        }

        Bla bla bla ...

        #endregion

    }
}

Meine Solution sieht wie folgt aus:

AppServer (Referenziert Appserver.api)
-> Appserver.cs // WinForms
-> App.config // Remoting Config File

AppServer.API (Referenziert nix)
-> Call.cs [Serializable]

EXTENSION

Contracts (Referenziert die Appserver.api)
-> ICallManager (Kein MBR Objekt o.ä.)
IcallManager hat als Rückgabewerte u.a. CALL Objekte , diese zeigen auf Appserver.api.Call

Services (Referenziert Appserver.api / Contracts )
-> CallManager MBR Objekt
CallManager arbeitet eben auch mit Call Objekten, welche auf Appserver.api.Call zeigen

WindowsGUI (Refenziert Appserver.api / Contracts)
-> Habe hier ein Usercontrol liegen, über welches z.b. ein Call Objekt geupdated werden muss

Windows CLIENT

Client (Referenziert die Appserver.api / Contract )
-> Programm selbst ... (sehr groß, besteht auch aus mehreren Projekten)
-> App.config

Mir ist nicht klar, wie ich auf Client Seite das richtige (CallManager) Objekt als Singleton aktivieren soll oder muss ?!

Vorher habe ich es so gemacht:


        try
        {
            object[] args = null;
            Call = (CTI_Integration.Call)(Activator.CreateInstance(typeof(CTI_Integration.Call), args));
            //Call.newClient();
            objNotCreated = (Call == null);

        }
        catch (RemotingException exp)
        { .......}

Das hat ja soweit geklappt, allerdings hatte ich auch die Verwaltung und das zu verwaltende Objekt in einer Klasse gebastelt, sodass das Objekt sich selbst in einer Liste verwaltet hatte , was sehr doof war 😛

Wenn ich jetzt aus dem Windows CLIENT den CallManager aufrufen möchte (liegt ja dann bei CTI_Integration.Extension.Services.CallManager) heisst es, es kann nicht aufgerufen werden, da ich keinen Zugriff darauf bekomme.

Der AppServer lädt also die CallManager Klasse als Singleton Objekt als WellknownType aus einer Konfigurationsdatei - das klappt soweit. (CallManager liegt NICHT beim Server, sondern in der Service Assembly, ich verweise nur in der App.Config auf die Manager Klasse).

Nur erschließt sich mir noch nicht wie ich Clientseitig das richtige Klassenobjekt jetzt WIE instanziere und dann ein entsprechendes Call Objekt rüberschiebe. (Call.cs Klasse , welche EIN Call Objekt beschreibt liegt momentan in der Appserver.API )

Habe wie gesagt den Developers Guide gelesen, aber da wir ja schon weiter sind als es in dem Guide beschrieben oder demonstriert wird , sehe ich vllt. gerade die Zusammenhänge nicht ganz die ich mit der Struktur erreicht haben soll.

Kurz, ich bin verwirrt - würde mich da über Hilfe freuen.

Vielen Dank und Gruß

Sebastian

Fragen, Diskussion, Kritik zu Projekt ".NET Applikationsserver"

B

Forenbeiträge von Bastor Ingesamt 62 Beiträge

Ich muss aber alle Objekte Cachen.

Tabellen sehen folgendermaßen aus:

Service

Service_Bereich