Frage zu WCF??
-
Dafür halte ich ASP.NET für naheliegender... die meisten Visualisierungstools arbeiten damit. Einen WebService als Transport für Visualisierungsdaten würde ich nicht unbedingt als 1. Wahl sehen, sondern eher in die Richtung ASP + Ajax gehen.
Die meisten kommerziellen Tools arbeiten auch auf dieser Basis, d.h. Backend in .NET, GUI mit ASP.NET und Visualisierung im Browser mit HTML und AJAX.
-
hmm ok hört sich nach viel arbeit an;) Ich dachte es gib evlt. möglichkeiten, das ich bspw. die benutzeroberfläche mit der maus zusammenbastle in VS die einezelnen control über eine schnittstelle zur programmlogik verbinde, und dann automatisch eine browser GUI version generieren lasse, so das ich lokal aber auch übers netz die anwendug steuere..
-
Das kannst Du letztlich mit ASP.NET und/oder WPF so machen. Stichwort "WebForms".
-
Ahh cool.. ich hab jetzt VB 2008 express gezogen, da kann man ne WPF App bzw. Webbroser dings da machen..
gehört das WPF prinzip unter die kategorihe "verteilte Anwendungen" ?
-
Mh also sorry, aber jetzt mal im Ernst...
Du hast studiert und dein Diplom bekommen?
Ist jetzt nicht böse gemeint.. aber so Sachen solltest du dir
a) echt selbst beantworten können und
b) eigentlich auch so wissen.Du vergleichst ein GUI-Framework mit Verteilten Anwendungen (oder wenn man so will "Middleware"). Da ist es noch sinnvoller Äpfel mit Brinen zu vergleichen
-
BorisDieKlinge schrieb:
Nun will ich von jedem Punkt der Welt aus , über die IP des Visu-Rechner auf diesen zugreifen wollen über einen browser, so das ich die Oberfläche des visurechner vor mir haben, so das ich die Anlage Fernbedienen bzw. Überwachen kann.
?Das kannst du in der Industrie gleich mal haken. Große Industriekunden sind mit ihrem Netzwerk seeehr empfindlich. XY beispielsweise lässt dich NUR in ihr Netz, wenn du einen aktuellen Virenscanner vorweisen kannst. Und Internet aus dem Netz eines Schwäbischen Automobilherstellers raus kannst du gleichmal ganz haken. Da sind nur bestimmte Rechner im Web. Und selbst da kommt oft ne normale zip oder rar nicht durhc. (Ich denke das verstösst gegen keine Vorschriften das zu schreiben.)
Andere große Firmen sind da auch nicht ebsser. Da kommst du zwar aus dem Netz raus, aber nicht rein. WENN die überhaupt Netz haben.
Bei vielen Konzernen ist es so, dass sie Standleitungen zur Zentrale haben und die alles verwaltet. Beispielsweise ein Weltweiter Konzern, den ich kenne... Da gehen alle Werke poer Standleitung nach Brüssel. DORT wird alles geschaltet und gewaltet. Wenn du da ran willst darfst du dich erst mit der Konzernmutter
rumschlagen. Das dauert und gibt Stress.Fazit: Wenn du Glück hast erwischste n Kleinen der dir einfahc Zugang gibt, weiler nur ne 0815-DSL-Leitung hat. Oder einen Großen der VPN-Zugänge erstellen kann.
Wir habens über den Rücken lösen müssen. Wir haben ISDN-Leitungen in den Werken für uns. Da ist ein Lancom 800i dran. In der Firma steht ein 1721. Wenn wirs rbauchen machen wir LAN-LAN-Kopplung, da wir dort unabhängige Netze stehen haben. Wenn wir von irgendwo ran müssen, gehen wir übers Web per VPN-client ins Firmennetz und dann von da weiter. Und auf die Oberfläche kommen wir zur Zeit per RealVNC. Bei der Neuentwicklung ist dann eine Schnittstelle per Sockets geplant.
Das is jetzt meine Erfahrung. Vielleicht ist es ausserhalb des Automotive und Kunststoff-Bereichs anders.
-
@Mods: Bitte den Namen des Herstellers zensieren. Hab ned gesehn, dass der ne Zeile drüber nochmal steht.
-
Shogun: wer spricht denn hier von IntERnet? Natürlich achtet man in einer großen Firma auf die Netztrennung, aber innerhalb des Produktionsnetzes kann man durchaus mit Webanwendungen (im IntRAnet) fahren. Das macht übrigens auch ein großer schwäbischer Automobilhersteller für seine MES-Anwendungen (Fa. FORCAM) teilweise so.
Oder daß man bei Maschinensteuerungen/Prozeßleitsystemen die Prozeßleitsysteme mit einer webbasierten Lösung erstellt - auch das ist inzwischen oft zu finden. Das kollidiert mit keiner Sicherheitsanforderung.
-
Ja hab das Diplom aber das .NET gedöns hat mich nie interessiert;)
die fragen könnte ich mir beantwort, aber hier gehts schneller.. und leute mit erfahrungen damit zu fragen ist besser..
Naja es geht lediglich darum eine anwendung zu programmieren welche lokal auf einem serverläuft, aber über das netz Steuerbar ist.. die GUI soll quasie lokal aber auch übers netz verfügbar sein...
-
BorisDieKlinge schrieb:
Ja hab das Diplom aber das .NET gedöns hat mich nie interessiert;)
GUI von Middleware unterscheiden zu können hat nichts mit .NET zu tun. Gerade ein gutes Abstraktionsvermögen sollte man doch durch das Studium gewonnen haben.
die fragen könnte ich mir beantwort, aber hier gehts schneller.. und leute mit erfahrungen damit zu fragen ist besser..
Alles klar.
-
Marc++us schrieb:
Shogun: wer spricht denn hier von IntERnet? Natürlich achtet man in einer großen Firma auf die Netztrennung, aber innerhalb des Produktionsnetzes kann man durchaus mit Webanwendungen (im IntRAnet) fahren. Das macht übrigens auch ein großer schwäbischer Automobilhersteller für seine MES-Anwendungen (Fa. FORCAM) teilweise so.
Oder daß man bei Maschinensteuerungen/Prozeßleitsystemen die Prozeßleitsysteme mit einer webbasierten Lösung erstellt - auch das ist inzwischen oft zu finden. Das kollidiert mit keiner Sicherheitsanforderung.
Klar Intranet zählt nicht. Ich bin ja auf die Angabe Weltweit angesprungen. Das bedeutet für mich im normalen Umfeld Internet. Denke da haben wir uns jetzt einfach nur missverstanden.
Wir haben ja auch bei unsrer Leitsoftware einen Webclient, damit im Intranet Zugriff möglich ist.
-
Shogun schrieb:
Ich bin ja auf die Angabe Weltweit angesprungen. Das bedeutet für mich im normalen Umfeld Internet. Denke da haben wir uns jetzt einfach nur missverstanden.
Intranet kann über das Internet erweitert werden. Stichwort VPN Tunnel.
-
Wie und wann ich das benutze ist egal;)
1. Es muss eine Anwendung sein, welche daten bereitstellt auf einem server.
2. ÜBer den Browser soll dann auf die daten zugegriffen bzs. visualisert werden.
3. Es sollen auch ActiveX Control angezeigt werden können (im Browser)
4. Lokal kann ja auch über den Browser auf die Daten zugeriffen werden köönnen (debugzwecke)
Naja sieht mir schon ehr nach WCF aus.
ASP.NET wäre auch ne lösungAch keine ahnung:(
-
Hallo nep ,
ich hab folgenden Artikel gefunden und gelesen
http://msdn2.microsoft.com/de-de/library/bb979121.aspx
anhand diese Artiikel sehe ich das ich genau sowas machen will..
nun is die frage wie ich die sache umsetzte?? reicht dafür VS2005/08 c# express versionen? Leider gibts keine beispielprojetek, für server/clientseitige programmierung
-
Eigentlich wollte ich ja nix mehr dazu schreiben, aber:
Das in dem Artikel ist .NET Remoting, was sozusagen der Vorgänger von WCF ist. Da .NET Remoting aber scheinbar keine allzu große Rolle mehr in Microsofts Strategie spielt (sprich es wird nicht weiterentwickelt und hat deshalb auch keine große Zukunft mehr; interessanterweise nutzt WCF ja auch Vorgängertechnologien wie z.B. COM, aber .NET-Remoting eben nicht).D.h. das was du vorhast kannst du dann ebenso gut auch mit WCF umsetzen, was wohl auch besser wäre, da zukunftsträchtiger.
-
achso oh man... jetzt hab ich mich schon gefreut was schönes zu finden:
Aber ich hab trozdem eine frage zu remoting:
Die Klasse bzw. das Objekt davon das geshared wird,wird ja bei (MBR) sozusagen vom server auf den client gespiegelt,
muss ich die klassendefintion welche ich per remoting vom server auf den client projezier in beinden anwendung deklarieen?
weil der client weis ja nich wie das objekt aussieht das deserialisiert werden soll?
P.S.: Wäre cool wenn es für die WCF alternative auch so einfach aussehen würde wie bei dem remoting... damit ich gleich mal ein funktionierendes bsp. hätte.
-
Hallo nep,
ich hab noch ne kleine frage, ich hab mir ja mal das "Remoting" angeschaut was ja der vorgänger von WCF ist.
aber ich finde keine beispiele bei WCF wie ich die MBR methodik aus remoting in WCF verwende? steh aufm schlauch
-
Ne da stehst du nicht auf dem Schlauch.
Alle Technologien im Middleware-Umfeld (sei es nun CORBA, RMI, oder eben .NET-Remoting) bieten sowohl eine Call-by-Value als auch eine Call-by-Ref Semantik (also dein MBR) an. Das ist bei WCF anders, da gibt es das so nicht. Im *Prinzip* wird hier ausschließlich eine Call-by-Value Semantik verfolgt. D.h. wenn du z.B. Daten hast die du zurückgeben willst von einem Service, dann werden die immer komplett serialisiert und an den Aufrufer übertragen.
Das hat mehrere Gründe warum man das bei WCF so macht. Hört sich vielleicht erst mal sehr einschränkend an, aber hat durchaus auch Vorteile, da du dich somit auch gar nicht um verteilte Objektreferenzen kümmern musst. D.h. du musst deine Interfaces eben auch entsprechend designen (z.B. nicht zu feingranulare Operationen in deinen Service-Kontrakten).
-
wenn ich nun aufm Client eine Instanz einer Klasse welche als service aufm server angeboten wird erzeuge, ist die Klasse dann physikalisch auf dem client im speicher erzeugt oder aufm server?
bzw. Werden die methodne einer SerciveContract klasse aufm server ausgeführt?
ist schon ne einschränkung, naja ich bin ja auch erst sei 2 tagen dabei das wcf zu verstehen:)
Ich möchtet testweise eine datenbank anbindung erstrellen, dabei sollen die abfragen der dagtenbank auf dem server ausgeführt werden und die ergebenisse im client dargestellt werden... mir fällt dazu die umsetzung der kommunukationsstruktiur zwischen server und client...
-
Natürlich werden die Methoden auf dem Server ausgeführt. Das was du als Client nachher in der Hand hast, ist lediglich der Proxy, der dir eben genau dies ermöglicht.
Wie schon mal gesagt, befasse dich erst mal allgemein mit Web Services oder sogar allgemein mit Middleware (lies z.B. ein Buch drüber). Dann wirst du vieles in WCF einfacher verstehen und auch verstehen warum einige Dinge so sind wie sie sind
(Und ich denke du wirst dann auch mehr verstehen, wie du z.B. deine Interfaces designen solltest).