PowerShell Remoting خاصية من أهم الخواص اللي تميز بيها PowerShell عن غيره من الـ Shells التقليدية. زي ما قولت قبل كده ان خاصية الـ Remoting بتوفر إمكانية تشغيل وتنفيذ أوامر PowerShell او ما يعرف بـ cmdlets على أي جهاز كمبيوتر داخل الـ network بشرط ان يكون PowerShell موجود (Installed) على الكمبيوتر ده.

على الرغم من أن PowerShell Remoting خاصية أكتر من ممتازة، لا يمكن إستخدامها في أي Workgroup environment أو peer-to-peer (P2P) network. يمكن إستخدامها فقط في Domain-Environment أو AD-Environment لأسباب أمنية (Security).

دلوقتي في Windows 7 بقي ممكن إستخدام خاصية الـ Remoting في أي workgroup أو Peer-to-Peer.

ملحوظة: قبل ما أبدء في الشرح يفترض ان يكون عندك 2 كمبيوتر (A,B) عليهم Windows 7  و Windows PowerShell v2 و التأكد من الـ 2 كمبيوتر في نفس الـ IP Add. range، على سبيل المثال الـ IP Address لكمبيوتر A هيكون 192.168.1.10 والـ IP Address لكمبيوتر B هيكون 192.168.1.20.

دلوقتي هنحاول أن احنا نفتح Remote Session من كمبيوتر A إلي كمبيوتر B عن طريق إستخدام أمر Enter-PSSession:

Enter-PSSession 192.168.1.20

هنلاقي أن PowerShell Console طلع Error بيقول ان في مشكلة في الـ WinRM. الموضوع ببساطة ان الـ Remoting بيعتمد على حاجة اسمها Windows Remote Management المسئولة عن إستقبال اي Remote Connection، سبب الـ Error هو ان الـ WinRM Service مقفولة على الـ Windows عشان هي Secure by default لأسباب أمنية.

الخطوة الأولي: تشغيل WinRM على كمبيوتر A و B

لتشغيل WinRM هنستخدم أمر  Set-WSManQuickConfig ، قبل متستخدم الأمر تأكد من:

•  ان ليك Administrative Privileges.
•  أنك عايز تشغل WinRM وقادر علي تأمين جهازك وشبكتك وده عشان الأمر ده بيعمل الآتي:
•  بيتأكد أن WinRM شغالة ولا مش شغالة بيشغلها.
•  بيغير الـ Start mode للـ WinRM Service ويبقي Automatic.
•  بيقوم بإنشاء Listner لإستقبال أي request من أي IP Address. دائما اي request بيتم عن طريق HTTP Protocol.
•  بيعمل Firewall Exception rule للـ WinRM Service عشان يتأكد ان الـFirewall مش هيقفل اي traffic يخص الـ WS-Management.

بمجرد كتابة الأمر Set-WSManQuickConfig و الضغط على Enter لتنفيذه، هتظهرلك رسالة توضح الـ 4 نقاط اللي اتكلمنا عليها

بعد التأكد من تنفيذ الأمر على كمبيوتر A و كمبيوتر B. هنحاول مرة تانية ان نفتح Remote Session من A إلي B عن طريق أمر Enter-PSSession. لكن هيظهر Error تاني بس السبب مختلف المرة دي. أول مرة كان سبب الـError هو ان الـWinRM Service مش شغالة. المرة سبب الـError هو ان الWinRM بترفض (Reject) أي request غير مُأمن بالـ Kerberos او على الأقل يكون بيستخدم نفس الـ Security mechanism أو ان الكمبيوتر اللي بيرسل الـrequest مش موجود في الـtrusted list في الكمبيوتر اللي بيستقبل، و بما أننا  بنستخدم Windows 7 على كمبيوتر A و B يبقي بنستخدم نفس الـ Security mechanism ،يبقي لنا ان الكمبيوتر مش موجود في الـ trusted list. والهدف منها هو التأكد من أن الكمبيوتر المحددة فقط هي المسموح لها بإستخدام خاصية الـ Remoting وليس أي كمبيوتر أخر.

قبل إضافة كمبيوتر B إلي الـ trusted list في كمبيوتر A.

هنستخدم أمر Test-WSMan عشان نتأكد ان على الأقل كمبيوتر A وكمبيوتر B قادرين على فتح Remote Sessions بينهم بغض النظر عن قبول او رفض الـ requests.

Test-WSMan 192.168.1.20

الخطوة الثانية: إضافة كمبيوتر A و B إلي الـ TrustedHosts list

الخطوة رقم 2 هي ان احنا هنعرف الـ WinRM على كل كمبيوتر على الكمبيوتر التاني عشان يسمح بإستقبال أي request لفتح اي remote session عن طريق إضافة الكمبيوتر في الـ trustedhosts list. على سبيل المثال عشان نسمح لكمبيوتر B ان يبعت request إلي كمبيوتر A يبقي لازم نُضيف الـ IP Address لكمبيوتر B في الـtrustedhosts list لكمبيوتر A. ويمكن كتابة “ * ” بدلاً من الـIP Address وفي هذه الحالة سيقوم الـWinRM بإستقبال اي Request من اي كمبيوتر وده بيكون عن طريق الأمر ده:

Set-Item WSMan:\localhost\client\trustedhosts * –force

الخطوة الثالثة: جرب و إستمتع…!!! :)

بعد تنفيذ الخطوة رقم 2 أصبحت خاصية  الـ remoting جاهزة للإستخدام.

Enter-PSSession 192.168.1.20

بعد لحظات من الضغط على Enter لتنفيذ الأمر (الفترة اللي بيفتح فيها الـremote session) هيظهر الـ PS prompt لكمبيوتر B. دلوقتي تقدر تنفذ اي cmdlet على كمبيوتر B من خلال كمبيوتر A عن طريق PowerShell Remoting.

يمكن إستخدام أمر Exit-PSSession عشان تقفل الـRemote Session.

One of the most compelling aspects of Flex is its ability to integrate with a wide variety of data sources. Many of the introductory tutorials online teach how to connect to http services to pull data. The result is typically an XML response. Flex makes it easy to manage XML but there are better ways. using XML requires an object on the server to be serialized to a text format which adds processing time. The response is also larger due to the variety of XML tags that need to be added in order to properly represent the object’s structure. Yes I hear you in the back telling me that JSON is a lighter weight response that doesn’t require all the tags. Regardless the response still needs to be parse out in the client. Finally the contract between client and server is not well defined with straight XML or JSON. Web services do provide a strict contract for the interface that the client can rely on but  the objects are still serialized with extraneous tags used to define the structure.

BlazeDS utilizes AMF to provide direct links between client and server objects. AMF provides access to objects through a binary protocol and eliminates the need to add additional tags that identify the object structure. It also reduces the work in flex to get the data back into a usable flex object.

Lets start working through an example by getting our workspace setup.

Initial Setup

Flex and Java both need to know about BlazeDS and where to look for the libraries and configuration files. FlashBuilder lends a hand with this by automating some of the process.

First things first, you’ll need to have FlashBuilder installed. The beta version can be downloaded at http://labs.adobe.com/technologies/flashbuilder4/.  Also check to make sure you have the WTP extensions installed in eclipse so you can automate creating the web application structure.

Finally for this IDE example we’re going to download the BlazeDS war from adobe at: http://opensource.adobe.com/wiki/display/blazeds/Release+Builds Just download the binary version, we don’t need the full turnkey for this. Once you have it downloaded, extract it to your drive, you should see the blazeds.war when you’re done.

In FlashBuilder create a new Flash project. Select J2EE Application server type. Select Remote object access with BlazeDS and the type. Select create combined Java/Flex using WTP. Click next.

On the next page, for the BlazeDS WAR file, point to the location where you extracted the files from Adobe. The system will pull all the jar files and configs from this war and add them to your project. Click finish.

You’ll notice that FlashBuilder loaded all the Jars and Config files as well as setting up the web.xml.

The web.xml tells java where to find the config files that BlazeDS needs. Remembering that Flex and Java are compiled separately and both need to know where configuration files are, lets find out where the IDE tells Flex about the config files.

Looking under the project properties under flex compiler you’ll see a compiler option is added for services.

NOTE: Without this compiler option Flex would not be able to find the BlazeDS services. When setting up blazeDS manually this flag will needed to be added by hand.

Java vs Flex: In Java the config files are loaded at run time. To change a value in the property file you simply need to restart the server to make it take effect. In Flex however this is a compile time include which means any changes to the files will need to be rebuilt into the application. Just a little note that may save you some headaches later.

That’s is for the setup.

Next time we’ll look at the code needed to use BlazeDS.  Stay tuned.

Schema- first contract-first modeling of Web Services gives you the ability to model your contracts with an XML-centric mindset. This process keeps you focused on universally acceptable types and the hierarchical data structures that can be represented in XML.

Schema-based Development with Windows Communication Foundation.

WCF and WF Services in .NET Framework 4.0 and “Dublin”.

What about BizTalk Server?

BlazeDS is a server-based Java remoting technology that allows you to connect to back-end distributed data and push data in real-time to Adobe Flex and Adobe AIR rich Internet applications (RIA).

You can get more information on BlazeDs on the following link “http://livedocs.adobe.com/blazeds/1/blazeds_devguide/”>

Below Are the steps to configure and run a Sample Program Using BlazeDS

Requirement:

Apache-tomcat-6.0.18 (download zip (pgp, md5) )

FlexBuilder

Step1:
Create a folder named BlazeDs in ${Tomcat}/webapps

Step2:
Download the BlazeDS Binaries from the following link
Download the BlazeDS binary distribution and extract it to ${Tomcat}/webapps/BlazeDs

step3:
Create a java Program “HelloWorld.java” in ${tomcat}\webapps\BlazeDs\WEB-INF\classes location

public class HelloWorld

{
public HelloWorld(){}
public String sayHello()
{
return “Hello World. It’s Working”;
}
}
compile and create the class file in the same location

step4:

Add the Following node in ${tomcat}\webapps\BlazeDs\WEB-INF\flex\remoting-config.xml

<service id=”remoting-service”  class=”flex.messaging.services.RemotingService”>
. . .
. . .

<destination id=”HelloWorld”>
<properties>
<source>HelloWorld</source>
</properties>
</destination>

. . .
. . .

</service>

Step5:
Create a new Project(name “BlazeDS”) using Flex Builder.

Copy and Paste the below code in BlazeDs.mxml

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”horizontal” >
<mx:RemoteObject id=”ro” destination=”HelloWorld” result=”resultHandler(event)” fault=”faultHandler(event)”/>
<mx:Panel x=”10″ y=”10″ width=”604″ height=”643″ layout=”absolute” backgroundColor=”#DFE8EC” cornerRadius=”6″ alpha=”1.0″ backgroundAlpha=”0.52″ borderStyle=”inset” fontWeight=”bold” themeColor=”#1611EF” color=”#1B3DE8″>
<mx:TextArea id=”text” text=”initial text” x=”240″ y=”61″ width=”273″ height=”56″/>
<mx:Text x=”62″ y=”10″ text=”Blaze DS Example” width=”431″ height=”28″ fontFamily=”Georgia” fontSize=”15″ alpha=”0.58″ color=”#389AAF” textAlign=”center” fontWeight=”bold” fontStyle=”italic”/>
<mx:Button x=”244″ y=”152″ label=”Click Me” fontStyle=”italic” themeColor=”#0B0BF6″ borderColor=”#291AE6″ click=”ro.sayHello()” />
<mx:Label x=”32″ y=”62″ text=”Data Returned from the server ” width=”189″ color=”#5BA9BA”/>
<mx:Button x=”338″ y=”152″ label=”Reset” fontStyle=”italic” themeColor=”#0B0BF6″ borderColor=”#291AE6″ click=”reset()”  width=”62″/>
</mx:Panel>

<mx:Script>
<![CDATA[

import mx.controls.Alert;

import mx.rpc.events.ResultEvent;

import mx.rpc.events.FaultEvent;

import mx.utils.ObjectUtil;

import mx.utils.StringUtil;

var str:String

private function resultHandler(event:ResultEvent):void

{

text.text= ObjectUtil.toString(event.result)

}

private function faultHandler(event:FaultEvent):void

{

Alert.show( ObjectUtil.toString(event.fault) );

}

public function reset():void{

text.text="initial text";

}

]]>
</mx:Script>

</mx:Application>

set the Additional compiler arguments for Flex Compiler

-services ${tomcat}\webapps\BlazeDS\WEB-INF\flex\services-config.xml -context-root /BlazeDs

Clean and build the Project again

now copy and paste the generated output files BlazeDS.html , BlazeDS.swf and AC_OETags files to ${tomcat}\webapps\BlazeDS\

Step6:

Stop and Start your tomcat server

Hit The Following URL

http://localhost:8080/BlazeDs/BlazeDS.swf  (or)

http://localhost:8080/BlazeDs/BlazeDS.html

Windows 7 и Windows Server 2008 R2 уже в состоянии RTM, а в них уже встроен PowerShell v2.0. Соответственно, самые прогрессивные администраторы уже смогут использовать PowerShell Remoting в реальном, не тестовом окружении.

Так как в целях безопасности Remoting разумеется отключён в конфигурации по умолчанию, то надо будет его включить. Сделать это можно с помощью командлета Enable-PSRemoting (причем надо выполнить его и на управляющем и управляемом компьютерах). Чтобы командлет не задавал лишних вопросов, достаточно добавить к нему ключ –Force.

Но как я уже сказал выше, время тестирования заканчивается, и скоро нам понадобится включать Remoting на множестве наших компьютеров. Enable-PSRemoting для этого уже мало подходит. Можно конечно включить его в сценарий загрузки компьютера, но это мягко говоря не эффективно.

И тут нам на помощь, приходят старые добрые групповые политики К сожалению (или к счастью?) галочка “сделать чтоб ремотинг заработал” отсутствует Так что с помощью групповой политики придётся произвести несколько отдельных настроек.

Во-первых надо создать “Listener”, так называемый “слушатель”, который будет принимать входящие подключения WinRM на определённый порт, с определёнными настройками. Listener’ов можно создать несколько, назначить различные разрешения на подключения к ним, порты, параметры безопасности, и ограничения. Но мы сейчас ограничимся созданием простого “слушателя” с настройками по умолчанию. Он будет принимать подключения от пользователей с административными полномочиями, на порт 5985. Создать его легко с помощью административных шаблонов групповой политики: Computer Configuration / Policies / Administrative Templates / Windows Components / Windows Remote Management (WinRM) / WinRM Service. Тут, в элементе Allow automatic configuration of listeners можно разрешить автоматическое создание “слушателя” по умолчанию, и указать для него диапазоны адресов с которых он будет принимать подключения (ipv4 и ipv6). Впрочем можно разрешить подключения отовсюду, поставив звёздочку (*). Рядом можно изменить некоторые другие настройки WinRM, или включить Listener’ы слушающие на портах 80 и 443 (Turn On Compatibility HTTP(S) Listener), стандартных для HTTP и HTTPS.

Ну и последняя настройка – разрешить подключения на соответствующий порт, в Windows Firewall. Делается это тоже с помощью групповых политик, в узле Computer Configuration / Policies / Windows Settings / Security Settings / Windows Firewall with Advanced Security / Inbound Rules.

Здесь просто нужно с помощью мастера, создать правило разрешающее подключение на соответствующие порты. Для этого можно использовать предустановленное правило Windows Remote Management.

Всё, теперь останется лишь подождать применения этой политики на компьютеры.

Ну и напоследок, файлы встроенной справки по Remoting’у:

PS C:\> get-help about_remote* | Format-Table Name, Synopsis -AutoSize

Name                         Synopsis
----                         --------
about_remote                 Describes how to run remote commands in Windows PowerShell.
about_remote_FAQ             Contains questions and answers about running remote commands
about_remote_jobs            Describes how to run background jobs on remote computers.
about_remote_output          Describes how to interpret and format the output of remote commands.
about_remote_requirements    Describes the system requirements and configuration requirements for
about_remote_troubleshooting Describes how to troubleshoot remote operations in Windows PowerShell.

Очень рекомендую с ними ознакомится.

# What’s a Windows process?
It’s an application that’s running and had been allocated memory.

# What’s typical about a Windows process in regards to memory allocation?
Each process is allocated its own block of available RAM space, no process can access another process’ code or data. If the process crashes, it dies alone without taking the entire OS or a bunch of other applications down.

# Explain what relationship is between a Process, Application Domain, and Application?
A process is an instance of a running application. An application is an executable on the hard drive or network. There can be numerous processes launched of the same application (5 copies of Word running), but 1 process can run just 1 application.

# What are possible implementations of distributed applications in .NET?
.NET Remoting and ASP.NET Web Services. If we talk about the Framework Class Library, noteworthy classes are in System.Runtime.Remoting and System.Web.Services.

# What are the consideration in deciding to use .NET Remoting or ASP.NET Web Services?
Remoting is a more efficient communication exchange when you can control both ends of the application involved in the communication process. Web Services provide an open-protocol-based exchange of informaion. Web Services are best when you need to communicate with an external organization or another (non-.NET) technology.

# What’s a proxy of the server object in .NET Remoting?
It’s a fake copy of the server object that resides on the client side and behaves as if it was the server. It handles the communication between real server object and the client object. This process is also known as marshaling.

# What are remotable objects in .NET Remoting?
Remotable objects are the objects that can be marshaled across the application domains. You can marshal by value, where a deep copy of the object is created and then passed to the receiver. You can also marshal by reference, where just a reference to an existing object is passed.

# What are channels in .NET Remoting?
Channels represent the objects that transfer the other serialized objects from one application domain to another and from one computer to another, as well as one process to another on the same box. A channel must exist before an object can be transferred.

# What security measures exist for .NET Remoting in System.Runtime.Remoting?
None. Security should be taken care of at the application level. Cryptography and other security techniques can be applied at application or server level.

# What is a formatter?
A formatter is an object that is responsible for encoding and serializing data into messages on one end, and deserializing and decoding messages into data on the other end.

# Choosing between HTTP and TCP for protocols and Binary and SOAP for formatters, what are the trade-offs?
Binary over TCP is the most effiecient, SOAP over HTTP is the most interoperable.

# What’s SingleCall activation mode used for?
If the server object is instantiated for responding to just one single request, the request should be made in SingleCall mode.

# What’s Singleton activation mode?
A single object is instantiated regardless of the number of clients accessing it. Lifetime of this object is determined by lifetime lease.

# How do you define the lease of the object?
By implementing ILease interface when writing the class code.

# Can you configure a .NET Remoting object via XML file?
Yes, via machine.config and application level .config file (or web.config in ASP.NET). Application-level XML settings take precedence over machine.config.

# How can you automatically generate interface for the remotable object in .NET with Microsoft tools?
Use the Soapsuds tool.

Seam bietet natürllich auch die Möglichkeit eines EventAustauschs zwischen mehreren Clients. Dazu wird Remoting in Verbindung mit JavaScript eingesetzt.

Ein Beispiel zur Implementierung ist bei Seam bereits enthalten: Der Chatroom

Allerdings ist dieser nicht zwangsläufig lauffähig, wenn man ihn denn in ein eigenes Projekt portieren möchte. Da unsere User aber später vielleicht ja auch miteinander chatten möchten, wäre die Funktionalität doch wünschenswert.

Diese kleine Doku setzt das Beispiel Chatroom aus Seam vorraus. Alle passenden Java-Dateien sollten sich dazu im Ordner main befinden, den Rest der Konfiguration gehen wir jetzt durch:

In meinem Fall ließen sich die Sourcen nicht fehlerfrei übersetzen. Dazu fehlten noch zwei Bibliotheken, die in das Projekt mit eingebunden werden müssen. Diese sind wie die anderen Bibliotheken auch zu finden. Es sind jms.jar & jboss-seam-remoting.jar. Eingebunden werden diese über Project –> Properties –> Java Sources Classpath –>Add JAR/Folder…

Ich hatte in meiner Konfiguration insbesondere Probleme mit dem Cache, daher habe ich diesen zunächst entfernt. Statt dessen muss man sich etwas anderes einfallen lassen, um die Benutzerliste aktuell zu halten. Ich bin da für ein Objekt, dass den Scope-Type Application hat und damit ebenfalls die Liste im Speicher halten kann.

Folgendes müssen wir in die components.xml einfügen:

<component name="topicPublisher" auto-create="true">
 <property name="topicJndiName">topic/chatroomTopic</property>
 </component>

 <component installed="true">
 <property name="allowedTopics">chatroomTopic</property>
 </component>

 <component name="org.jboss.seam.remoting.remoting">
 <property name="debug">false</property>
 <property name="pollTimeout">2</property>
 <property name="pollInterval">1</property>
 </component>

Anschließend muss die passende Service-Datei (im Beispiel jboss-seam-chatroom-service.xml) in das Projektverzeichnis kopiert werden und folgende Zeilen in die web.xml eingefügt werden.

<servlet>
 <servlet-name>Seam Remoting</servlet-name>
 <servlet-class>org.jboss.seam.remoting.SeamRemotingServlet</servlet-class>
 </servlet>

 <servlet-mapping>
 <servlet-name>Seam Remoting</servlet-name>
 <url-pattern>/seam/remoting/*</url-pattern>
 </servlet-mapping>

Jetzt sollte  das Remoting funktionieren…

Sobald ich dann herausgefunden habe, wie der Cache problemlos aktiviert werden kann, werde ich das natürlich nachreichen – denn sonst hängen unsere User als Dateileichen im Chat herum…

In einem aktuellen Projekt bestand das Problem, dass wir einen .NET Remoting Server implementiert hatten, der den TcpChannel als Transport verwendet. Das Problem entstand dadurch, dass der Server mit mehreren Netzwerkadaptern (LAN und WLAN) ausgestattet war und die IP-Adresse des WLAN-Adapters sich dynamisch ändert weil der Server auf einem mobilen Gerät läuft, das herum getragen wird (“roaming users”) und sich mit verschiedenen WLAN-(Sub)netzen verbindet. All das wäre noch kein Problem wenn es im Netzwerk des Kunden einen DNS-Server gäbe. In diesem Fall könnte man den TcpChannel so konfigurieren, dass er den Rechnernamen des mobilen Servers für die Bindung der Proxies verwendet. Da aber kein DNS zur Verfügung steht, mussten wir auf die Option useIpAddress=”true” ausweichen. Dadurch entstand eine Reihe von Problemen:

1. Wenn beim Start des Systems (Windows XP Embedded) kein Netzwerkkabel angesteckt ist und kein WLAN verfügbar ist, wird der Maschine keine IP-Adresse zugewiesen. Eine Kommunikation mit dem Gerät über den .NET Remoting TcpChannel ist dann auch nach dem Herstellen einer Netzwerkverbindung nicht möglich (der .NET Remoting Server läuft als Win32 Service und wird beim Systemstart automatisch gestartet).
2. Wenn sich die IP-Adresse des WLAN-Adapters zur Laufzeit des .NET Remoting Service ändert, dann war keine Kommunikation mit dem .NET Remoting Service möglich. Selbst dann nicht, wenn der Client neu gestartet wurde. Der Client kennt zwar die neue IP-Adresse und kann den Server anpingen und sogar eine TCP Verbindung zum .NET Remoting Interface herstellen, eine Kommunikation über das .NET Remoting Protokoll war jedoch nicht möglich.

Ursächlich hierfür ist die Implementierung des TcpChannels im .NET Framework (2.0 SP1, neuere Versionen sind aber auch nicht besser). Bereits beim Registrieren des TcpChannels (z. B. via RemotingConfiguration.Configure) werden die IP-Adressen des Hosts ermittelt und der TcpChannel wird an die erstbeste(!) IP-Adresse (und zwar nur an diese!) gebunden. Diese Bindung bleibt bis zum Ende des Prozesses bestehen. Sie passt sich nicht dynamisch an. Ein nachträgliches Umkonfigurieren ist nicht möglich da die Klasse TcpChannel hierfür keine Properties/Methoden zur Verfügung stellt. Selbst ein explizites Deregistrieren (ChannelServices.UnregisterChannel) mit anschließender Neuinstanziierung und Neuregistrierung (ChannelServices.RegisterChannel) des TcpChannels ist nicht möglich weil das .NET Framework die Registrierung eines TcpChannels nur ein einziges Mal zulässt (warum?).

Zur Lösung des Problems haben wir eine eigene Implementierung des TcpChannels erstellt. Als Vorlage diente der Sourcecode von mono 2.4. Damit war es möglich, den TcpChannel zu de- und anschließend wieder zu registrieren. Im Gegensatz zum Standard-TcpChannel aus dem .NET Framework liefert unser TcpChannel nicht nur eine einzige URI für ein Objekt, sondern eine Liste von URIs, die einen Eintrag für jede dem System zugewiesene IP-Adresse (gefiltert auf IPv4) liefert. Parallel dazu haben wir einen “TcpAddressMonitor” implementiert, der die dem System aktuell zugewiesenen IP-Adressen überwacht (mittels Polling im 5 s Takt) und bei einer Änderung den TcpChannel deregistriert, eine neue Instanz erstellt und diese wieder registriert. Damit waren sowohl das Problem mit nicht vorhandenen IP-Adressen beim Systemstart als auch das Roaming-Problem gelöst.

Allerdings wurden nun Exceptions, die beim Aufruf von Server-Methoden auftraten, nicht mehr an den Client durchgereicht. Die Option RemotingConfiguration.CustomErrorsMode=CustomErrorsMode.Off wurde ignoriert. Clientseitig kam lediglich eine RemotingException mit der Message “Server encountered an internal error” an. Die Lösung für dieses Problem fand sich hier: Es muss im TcpChannel der RequestHeader __CustomErrorsEnabled=false gesetzt werden. Auf diese Lösung bin ich nur dadurch gekommen, dass ich mir den gesamten verfügbaren .NET Sourcecode über den NetMassDownloader heruntergeladen und nach “customErrors” durchsucht habe.

Update, 13.05.2009: So ganz hat der oben beschriebene Weg doch nicht funktioniert. Wie sich gezeigt hat, gibt es Probleme mit bereits gemarshalten Objekt-Referenzen (ObjRef) wenn der TcpChannel neu registriert wird. Die Referenzen werden dann ungültig. Da hilft nicht einmal ein Neustart der Clients. Anhand eines Analyse des Quellcodes habe ich folgendes gelernt:

1. Jeder Channel enthält eine Liste von URIs (beim TcpChannel wird die Liste von der internen Klasse TcpServerChannel verwaltet).

2. Jede Objekt-Referenz enthält eine Liste von URIs (z. B. “tcp://hostname:port/xxxxxx.rem”).

Wird eine Referenz zum ersten Mal gemarshalt, wird ein ObjRef Objekt erzeugt. Dabei wird die Liste aller URIs aller in .NET Remoting registrierten Channels in das ObjRef Objekt kopiert.

Um unser Problem der sich ändernden IP-Adressen zu lösen, war nun folgendes nötig sobald sich die IP-Adressliste des Hosts geändert hat:

1. Die URI-Liste jedes TcpChannels muss aktualisiert werden.

2. Die URI-Liste sämtlicher Objekt-Referenzen muss aktualisiert werden.

Das ließ sich folgendermaßen implementieren:

1. Die Liste aller registrierten TcpChannels erhält man über ChannelServices.RegisteredChannels. Mit Hilfe von “… is TcpChannel” wird überprüft, ob es sich um einen Channel vom Typ TcpChannel handelt. Um den TcpChannel aktualisieren zu können, wurde eine public Methode UpdateChannelData() hinzugefügt. Diese delegiert einfach an eine ebenfalls neue Methode UpdateChannelData() des internen TcpServerChannels. Damit waren die URIs des TcpChannels aktualisiert, was allerdings nur Auswirkungen auf zukünftige gemarshalte Objekt-Referenzen hat.

2. Die bereits gemarshalten Objekt-Referenzen können aktualisiert werden, indem die Schnittstelle ITrackingHandler von einer Klasse TrackingHandler implementiert wurde, und eine entsprechede Instanz beim TrackingService registriert wurde. ITrackingHandler wird benachrichtigt, wann immer eine Objekt-Referenz gemarshalt, unmarshalt oder disconnected wird. Beim Marshaling vermerkt unsere Klasse die erzeugte Objekt-Referenz in einer Liste, beim Disconnect wird die Objekt-Referenz aus der Liste entfernt. Anhand dieser Liste lässt sich leicht über alle bereits gemarshalten Objekt-Referenzen iterieren und deren URIs aktualisieren.

http://www.news.com.au/technology/story/0,,24510547-5014118,00.html

In one of my earlier posts i described a method for uploading files using the RemoteObject class found in the Flex SDK. For the “back end” i used the still very popular amfphp implementation of the AMF protocol.

Wade Arnold the maintainer of amfphp is also involved in another implementation of the AMF protocol which is shipped with the Zend Framework. After reading some blog posts about this “new” package called Zend_Amf, i decided to give it a try.

Download ZendAMFUpload.zip for full example code.

I started my quest with downloading of the latest Zend Framework library, which is now at version 1.7.8 and followed the instructions of the Quickstart guide, which can be found here.

I also found a great post from Piotr Walczyszyn about how to merge the Zend_Amf package within the Zend Framework MVC structure and i used this approach as a starting point for my own example, but made the following changes compared to the tutorial of Piotr:

1)
Because i don’t use a database within my example i removed all code related to the config, database and registry from my bootstrap.php file.

2)
Somehow the disableLayout call in the MessageBrokerController init function Piotr provided resulted in an error, so i removed this line.

3)
Instead of putting my data objects into a dto folder i used a folder named vo. It is the same, but i am used to call my remote data objects Value Objects.

4)
During my quest i stumbled to some strange behaviour when sending Typed Objects (FileVO) from my flex client to the service layer. According to the Zend_Amf documentation you could use $_explicitType within a ValueObject for mapping serverside PHP classes with AS3 classes, but this only worked for retrieving typed objects, not for sending typed objects. Finally i found these issues related to class mapping of typed objects: ZF-5755, ZF-5885 and ZF-6130, and decided to use the $server->setClassMap call in my MessagebrokerController.

Here is the code i ended up with:

MessagebrokerController.php

class MessagebrokerController extends Zend_Controller_Action {
// Initialise controller with no view renderer
public function init() {
$this->_helper->viewRenderer->setNoRender(true);
}
// amf action
public function amfAction() {
$server = new Zend_Amf_Server();
$server->addDirectory(APPLICATION_PATH . '/services/');
// Mapping of PHP FileVO class and AS3 FileVO class
$server->setClassMap("FileVO", "FileVO");
echo($server->handle());
}
}


FileVO.php


class FileVO {
public $filename;
public $filedata;
}


RemoteFile.php


class RemoteFile {
/**
* Upload files!
*
* @param $file as a FileVO Object
* @return string
**/
public function upload($file) {
$data = $file->filedata;
file_put_contents( APPLICATION_PATH . '/uploads/' . $file->filename, $data);
return 'File: ' . $file->filename .' Uploaded ';
}
}


I kept the flex code the same as in my earlier post except for the remote service endpoint url, which should be now something like

http://[some-host]/messagebroker/amf

Download ZendAMFUpload.zip for full example code.

File upload with Adobe Flex is a common asked feature for lots of applications. There are several posts on the internet to be found which explain, in detail, how to do this.

Most of these examples however uses the http protocol to transport the binary data. With the arrival of the Adobe Flash 10 player and the new FileReference features that comes with it, it is now also possible to upload a file via a RemoteObject service call.

For the coming example it is assumed that amfphp 1.9 and Flash player 10 (Flex 3.2 SDK) is installed and running. Furthermore i am using a setup as described in one of my earlier posts about RemoteObject and AMFPHP. Download PHPUpload.zip for full example code.

Copy the services contents found in the zip to your amfphp services location (and check the amfphp/globals.php if your “vo” location is configurated to “services/vo/”).

Within your services directory a RemoteFile.php can be found with a public function upload, which require a parameter of type FileVO:


require_once ('./vo/FileVO.php');
class RemoteFile {
/**
* Upload files!
*
* @param FileVO $file
* @return string
**/
public function upload(FileVO $file) {
$data = $file->filedata->data;
file_put_contents( 'uploads/' . $file->filename, $data);
return 'File: ' . $file->filename .' Uploaded ';
}
}


The FileVO php class has a Flex counterpart also called FileVO which is used as a so called RemoteClass. This RemoteClass has an attribute for the filename and filedata (ByteArray).

No we are ready to create the service class for the upload example, this class will be named RemoteFileService and extends the RemoteService super class.public class RemoteFileService extends RemoteService {
private static var phpServiceClass:String = "RemoteFile";
//constructor
public function RemoteFileService(amfChannelId:String, amfChannelEndpoint:String) {
super("remotefileService","amfphp", amfChannelId, amfChannelEndpoint);
}
// Upload function
public function upload(file:FileVO):void {
remoteObject.source = phpServiceClass;
remoteObject.upload.addEventListener(
ResultEvent.RESULT,handleRemoteMethod);
remoteObject.upload(file);
}
// Remote result handler
protected function handleRemoteMethod(event:ResultEvent):void {
var uploadStatus:String;
uploadStatus = event.result.toString();
Application.application.dispatchEvent(
new RemoteResultEvent(RemoteResultEvent.UPLOAD_STATUS, uploadStatus));
}
}

The Flex application file contains a text component (which will be filled with the selected filename), a button for selecting a file and a button to start the upload. Download PHPUpload.zip for full example code.

After a succesfull upload the selected file will be placed in the amfphp/services/uploads directory (needs write privileges!) and an Alert shows a message from the server.

Flash Remoting (AMF3를 활용한) 서버로 .NET 기반의 솔루션을 사용한다면

생각해 볼 수 있는 구성

- WebOrb
- Flourine Fx

우리는  ’Flourine Fx’를 선택했다. 이유는… Free / Support .NET Framework 1.1 ~ 3.5 (최초 개발 당시 우리 플랫폼은 .NET 1.1 기반이었고, 지금은 3.5) 

특징

- 진짜 빠르다.
- 좀 많이 쉽다.
- Flex 뿐만 아니라 Silverlight도 사용 가능하다!!

Download: source code

Folosi-ti FileZilla pentru serverul de FTP.
1 ) Dezarhiva-ti sursa
2 ) Deschide-ti proiectul Remoting.sln
3 ) Selecta-ti WindowsService1 ca StartUp Project(click dreapta pe el) apoi Build (F6)
4 ) Start -> Programs -> Microsoft Visual Studio 2008 -> Visual Studio Tools -> Visual Studio 2008 Command Promt -> Apare o fereastra
5 ) Introduce-ti in fereastra de la Command Promt calea unde ati dezarhivat proiectul, apoi intra-ti in Remoting->WindowsService1->bin->Release si executa-ti urmatoarea comanda:
installutil WindowsService1.sln

Va aparea:
The Commit phase completed successfully.
The transacted install has completed.

6 ) Click dreapta pe My Computer -> Manage : Apare o fereastra Computer Management
In Services and Application selecta-ti Services, cauta-ti AlexFTP si da-ti Start.

7 ) In Visual Studio selecta-ti acum Remoting ca fiind StartUp Project si rulati-l (CTRL+F5).
In fereastra care apare pute-ti selecta serverul (poate fi si local host daca folositi FileZilla), portul (nu prea are importanta), userul si passul pentru a va putea conecta la server.
Butonul Files este pentru a afisa lista de fisiere de e server din directorul curent.
Pentru Download se va mentiona in TextBox numele fisierului care se doreste a fi downloadat si apoi se apasa pe butonul Download.
ListBoxul retine o istorie a operatiilor executate.

8 ) In directorul Remoting al proiectului -> bin -> Release se gaseste un fisier alex.xml in care se va retine istoria operatiilor.

9 ) La sfarsit:
Executa-ti urmatoarea comanda in fereastra de la Command promt:
installutil /u WindowsService1.sln

Va aparea:
The uninstall has completed.

The first release of BlazeDS and Spring integration has just been released. Jeremy’s blog provides a detailed writeup on how to get your Blaze DS and Spring project up and running.

This release addresses the basic bootstrapping and RemoteService. Please watch out for updates such as

1. REST Support
2. Integration with Spring Security
3. Integration with Blaze DS Messaging

Note: The same configuration described by Jeremy should work with LC DS. If anyone has tried this configuration, let me know.

Got comments? Feel free to contact me, but the best way to get your feedback is to participate in the Spring Blaze DS Integration Forum

2 reasons

Reason 1: Remoting = Faster performance

Flex enables applications to communicate with the server over AMF, a faster binary alternative to String encoding. If your business logic is available in Java, Blaze DS offers Remoting that enables Flex applications to direct communicate with your business logic over AMF.

Note: The fundamental difference between flex applications and web application is that you don’t generate your presentation logic on the server. The communication between the Flex client and your server (Blaze DS) is primarily data. Hence your application performs much faster than a typical web application.

Reason 2: Messaging = Live Flex Applications

The request response nature of HTTP makes it very challenging to create web applications that are not static with out any user interaction. Remember when you watching NFL (any sport scores) on the Internet, your screen updates every 2 minutes to get the latest scores. It is annoying and inefficient. Blaze DS offers a messaging infrastructure that enable you to build server applications that can push messages to Flex Application. Flex applications using Blaze DS don’t have to blink anymore.

To top it, Blaze DS is Open source and Free to use in production

Well… I have several things that I want to post on this blog and since this blog is a place where I will be storing bits of information, my first bit if information will be my To-Do List. Here is a list of the things that I will be posting soon:

1. Using C# to open a DCOM application on a local and remote machine.
2. Writing an application that does not appear in the Windows taskbar and has an icon in the notification area (aka system tray).
3. Serialization of an object using Visual C#.
4. File and directory access using Visual C#.
5. Using the CryptoStream class to save data to a file.
6. Working with the registry using Visual C#
7. Simple .NET Remoting example

I’m sure that I will come up with more ideas that will make their way to this blog so stay tuned. If there are any topics that you would like me to post about please let me know!

So I was quite bored recently and I just wrote up some automated script to update a blog from this website over to Xanga except that they thought I was a bot and removed my post. Oh well, at least I tried.

I was just hoping that if that was possible, then I would still really be maintaining one blog but do multiple postings on multiple blogs. But now it’s getting a little hard so I’ll post there when I feel like it.

Anyways now I’ve ditched my XML-RPC tool and an using the Windows Live Writer to auto post onto WordPress and it’s pretty good. As this is a first post, let’s hope it doesn’t go screwy.

In my daytime job i am currently involved with a Flex3/BlazeDS project.The question arises to me quickly if it was possible to use Actionscript 3 RemoteObject classes with a PHP back end. A quick search with Google showed me some examples where Flex mxml in combination with amfphp 1.9 was used. This particular version of amfphp has support for AMF3 messaging protocol and therefore can be used natively with AS3 RemoteObject.

In my example i wanted to do something different by using AS3 RemoteObject classes and creating Channels at runtime, so no server-config.xml is needed during compile time.

For the coming example it is assumed that amfphp 1.9 is installed and running. for the backend service i use a slightly changed HelloWorld.php which can be found in the amfphp examples:

class HelloWorld {
/**
* Say hello!
*
* @param string $sMessage
* @return string
**/
public function say($sMessage) {
$date = getdate();
if (!$sMessage) {
throw new Exception("No message has been given",10001);
}
return 'You said: ' . $sMessage .' on '.$date[weekday];
}
}
?>

I introduced a PHP exception when no message parameter is given.
The next step involves the creation of the RemoteService super class. The constructor method is shown below (download PHPRemoting.zip for full example code).

public function RemoteService( serviceId:String
, serviceDestination:String
, amfChannelId:String
, amfChannelEndpoint:String
)
{
// Create a runtime Channelset for given Channel ID and Endpoinr URI
var amfChannel:AMFChannel = new AMFChannel(amfChannelId, amfChannelEndpoint);
amfChannelSet = new ChannelSet();
amfChannelSet.addChannel(amfChannel);
// Create the remoteObject instance
this.remoteObject = new RemoteObject(serviceId);
this.remoteObject.channelSet = amfChannelSet;
this.remoteObject.destination = serviceDestination;
this.remoteObject.addEventListener(FaultEvent.FAULT,onRemoteException);
}

All new service classes will extend this RemoteService super class and inherit all methods available.

No we are ready to create the service class for the HelloWorld example, this class will be named HelloWorldService and extends the RemoteService super class.

package remoting.services
{
import mx.controls.Alert;
import mx.rpc.events.ResultEvent;
import mx.core.Application;
import remoting.events.RemoteResultEvent;
/**
* Class that extends the RemoteService class, therefore it makes use of the default error handling for
* remote calls.
*/
public class HelloWorldService extends RemoteService {
// Static var with the PHP classname
private static var phpServiceClass:String = "HelloWorld";
//Constructor
public function HelloWorldService(amfChannelId:String, amfChannelEndpoint:String) {
super("helloworldService","amfphp", amfChannelId, amfChannelEndpoint);
}
//
public function say(msg:String):void {
remoteObject.source = phpServiceClass;
remoteObject.say.addEventListener(
ResultEvent.RESULT,handleRemoteMethod);
// call the PHP method
remoteObject.say(msg);
}
// Result handler
protected function handleRemoteMethod(event:ResultEvent):void {
var helloworld:String;
helloworld = event.result.toString();
Application.application.dispatchEvent(
new RemoteResultEvent(RemoteResultEvent.HELLO_WORLD, helloworld));
}
}
}

There is only a resulthandler implemented for the remoteobject call, because the fault handler is already implemented within the RemoteService super class. Important thing is the static var phpServiceClass which contains the name of the PHP class which will be binded to the remoteObject.

Now the plumbing is ready (download PHPRemoting.zip for full example code) it is time to create the Flex application file. This example application has a TextInput box for the message and a Button to call the remote method.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
layout="vertical"
creationComplete="init();">
<mx:Script>
<![CDATA[
import remoting.events.RemoteExceptionEvent;
import remoting.events.RemoteResultEvent;
import remoting.services.HelloWorldService;
import mx.controls.Alert;
//
private var amfChannelId:String = "my-amfphp";
private var amfGateway:String = "http://localhost/amfphp/gateway.php";
private var service:HelloWorldService;
// Initialization
private function init():void {
this.addEventListener(RemoteExceptionEvent.REMOTE_EXCEPTION, handleRemoteExceptionEvent);
this.addEventListener(RemoteResultEvent.HELLO_WORLD, handleRemoteResultEvent);
// Create a new service instance
service = new HelloWorldService( amfChannelId, amfGateway );
}
// Button action handler
private function clickHandler():void {
service.say(msg.text);
}
// Result handlers
private function handleRemoteResultEvent(event:RemoteResultEvent):void {
Alert.show(event.message);
}
private function handleRemoteExceptionEvent(event:RemoteExceptionEvent):void {
Alert.show(event.message);
}
]]>
</mx:Script>
<mx:TextInput id="msg"/>
<mx:Button label="say something" click="clickHandler();"/>
</mx:Application>

When no text is provided the PHP class will throw an exception which is shown in the Alert box. Just try it out.

Oh no they didn’t.  Wait they did!

WebORB is the kitchen sink and then some.  For many of us, just the AMF transport ( “The ABC’s of AMF.” ) of G-zipped SON blobs is all we will ever need, but you never know what you really need until you have to live without it.  One spin around WebORBs management console and your needs will change forever.

It is as easy as 1,2,3.

1. Pick your favorite server technology and install the WebORB server.  I chose .NET.

Hit your WebORB service and you are presented with the management console.  If for some reason you are not, the folks at http://www.themidnightcoders.com/ have created a start page that might just point out exactly what you have to do to get your service up and running.  In my case I was installing it on a Windows Server 2008 VM and it did require some extra attention to get the gateway going.  Once I pushed past this everything was straight forward.

The management console has everything you need to begin to develop with this technology, there is no need to go back to the http://www.themidnightcoders.com/ for docs and examples.  See the console main tabs below.

One cool thing is that the examples are running right there on your server providing the proof that the gateway is functional, there is no question if the code you are writing does not work that it is a server issue.

2. Follow the instructions on how to create a C# data class file and code up a test method, I suggest having at least 1 parameter on this method to make it a realistic test. Compile it and drop it in the WebORB bin folder.

Now for some real magic, go back to the management tab on the console and you will see your DLL listed in the Deployed Assemblies tree control on the Services sub tab.  Expand that DLL, Expand your namespace, expand your service name and presto, there is your test method.  One nice thing about WebORB is that it respects the access specifiers of (public, private, protected) and will not show private methods in this tree (or allow calls via the gateway).  Click on your test method name and the right panel changes to a form that allows you to test your method with params!!!  You didn’t even have to write any client code to test your server code, they are fricken’ holding our hands here people…  Now, go back to the Deployed Assemblies column and click on your service parent.   The Code Generator Tab should show up.  This is actually usable code that mimics the server API on the client, this was my “aye Dios mio” moment.  Now for the capper,  look to the right panels Code format / style and choose your client technology from a long list including Cairngorm, PureMVC, AJAX client, and ARP framework.  Did I mention WebORB is “Free“?

3. Chose the client example that best fits your need and take the pieces you need for your project, change the properties to match your namespace and method names, and wallah, you are transmitting data in arguably one of the the most efficient manners possible across the wire.

As I said, this is just the tip of the iceberg when it comes to WebORB features.  Click around the console and see for yourself just how powerful and feature rich this package is, you will amazed.

My hat is off and I am fully bowed to The Midnight Coders for unequaled performance and delivery of a very usable data service.  Just what does all this other stuff do!

Note:

AMFPHP is pretty decent and may have everything you need.  My team at Method used AMFPHP in our Flex projects during my tenure.  We didn’t know about WebORB at the time or I am certain we would have used it.

Feature Request:

Please make the value fields in the results object browser selectable.  It is a real pain to type in a .net GUID into the params value field for an invocation of a method that is keyed off of that GUID.  Better yet, make it a right click on the result value field and send to param (of choice) option.

A arquitetura em camadas tem sido amplamente adotada pelos analistas e desenvolvedores de sistemas computacionais. Isso porque esta arquitetura favorece a aplicação de vários conceitos envolvendo a engenharia de software como, por exemplo, modularidade, manutenibilidade, etc. O conceito que motivou a escrita deste post é a escalabilidade, ou seja, o desafio de construir sistemas preparados para “crescer”. Um sistema e dito escalável, por exemplo, quando seu desempenho aumenta com acréscimo de hardware. Não estou falando em ficar mais rápido por que agora ele está rodando em um servidor mais rápido do que o antigo. Estou falando em potencial de crescimento e adaptação a cenários de produção. Imagine a situação: Uma pequena empresa com poucos recursos financeiros requisitou da equipe de TI um sistema de gestão empresarial. Após levantamento de requisitos, avaliação das condições de infraestrutura, decidiu-se pela seguinte configuração: arquitetura cliente/servidor. Um servidor de banco de dados foi colocado na rede e a aplicação cliente faria solicitações a este servidor. A aplicação cliente implementava todas as regras de negócio do sistema de gestão e o servidor de banco de dados serviria apenas como repositório de dados. A princípio tudo funcionava bem: LAN com poucos usuários, poucos dados no banco… Mas a empresa cresceu. Mais usuários na rede, maior volume de dados, novas filiais, negócios via internet, novas regras de negócio, etc. Já está claro que o velho sistema precisaria ser reescrito. Talvez até em outra plataforma de desenvolvimento. Sem falar que, possivelmente, novos especialistas em TI precisarão ser contratados ou, pelo menos, os anteriores terão que passar por algum treinamento/reciclagem. Tudo isso porque não se pensou na possibilidade do sistema crescer em necessidades de regras de negócio juntamente com a necessidade de infraestrutura. A pequena empresa, hoje, tem condições para investir em mais computadores-servidores, internet, redes de longa distância. Ela tem alto volume de dados que precisam ser tratados com velocidade dentro e fora do ambiente da empresa. Eu pergunto: é qualquer sistema que pode se adaptar a esta nova realidade? O grande desafio é CONSTRUIR SISTEMAS PREPARADOS PRA CRESCER. O sistema não precisa nascer grande mas deve possuir características que, com pequenas adaptações, tenha seu potencial aumentado.

Um bom começo para quem prentende trabalhar com escalabilidade é verificar se seu sistema admite a possibilidade de trabalhar utilizando um servidor de aplicação: as aplicações clientes (desktop ou web) fazem requisições a um servidor. Neste servidor estão implementados todas as regras de negócio e esse servidor faz acesso ao banco de dados para, então, responder às solicitações. Para utilizar essa proposta, que modificações voce teria que fazer no seu sistema?

1. Teria que reescrever o sistema em outra plataforma?
2. Teria que efetuar algumas mudanças sim. Voce acha que dá pra fazer? Em quanto tempo?
3. Teria que, primeiro ser treinado em ambiente em camadas pra depois pensar nisso?
4. Teria que, primeiro mudar sua forma de programar?
5. Teria que colocar as regras de negócio da aplicação em um só lugar para depois pensar no servidor de aplicação?
6. Teria que modelar o sistema primeiro em orientação a objetos?
7. Outro “teria” qualquer….

Veja que parece simples responder a esta pergunta mas não é tão imediato assim. Nem todos os sistemas são preparados para isso efetivamente. Outras respostas:

1. Construimos o sistema com esta visão. Foi previsto que o projeto teria grande possibilidade de crescimento tanto em recursos quanto em necessidades.
2. Sim. É só modificar o arquivo de configurações do sistema para que as aplicações clientes façam solicitações para o servidor.
3. Sim. Só preciso modificar uma linha do sistema, recompila-lo e recoloca-lo em produção.
4. Quantos servidores posso utilizar? Pelo menos um servidor para DAO´s e banco de dados e um outro servidor de regra. Poderiam ser mais servidores de aplicação espalhados pela rede. Depende apenas do nível de resposta que a empresa pretende ter e da disponibilidade de recursos físicos.
5. O sistema permite dividir papéis facilmente.
6. Outros “só se for agora” qualquer….

Se voce puder utilizar alguma dessas respostas, parabéns. Voce já está no caminho certo. É essa linha que a engenharia de software moderna quer que os novos sistemas sigam. Para aqueles que aindam não perseguem estes objetivos vou tentar passar algumas dicas como roteiro inicial a seguir.

Eu utilizava .NET 1.1 quando me fiz a seguinte pergunta: Em J2EE, pode-se configurar a utilização de um servidor de aplicação através dos EJB containers. JBoss é um exemplo de servidor de aplicação gratuito em Java. Qual o servidor de aplicação para .NET??? Há um tempo atrás fui a uma apresentação sobre .NET 2.0 com Visutal Studio 2005. Na saída fiz essa pergunta ao facilitador e ele me respondeu com uma palavra: “Remoting”. Ao chegar em casa me dediquei a pesquisar sobre o assunto. A seguir, deixo indicado um artigo que serviu de base para nossa trajetória sobre o assunto:

.NET Remoting – Parte 1 – Acessando informações remotamente
.NET Remoting – Parte 2 – Acessando informações remotamente

Desde então temos trabalhado para que a construção dos nossos sistemas tenham carateríscas que viabilizem a arquitetura de acesso remoto. As pessoas que acompanharam em nosso blog os post entitulados NHIbernate + Visual Studio: Construindo aplicações em camadas devem ter notado em algumas partes dos códigos e da explanação a presença de flags para utilização de servidor de aplicação. Desenvolvemos uma solução chamada RemoteServer.NET em Visual Studio com 3 projetos que casa perfeitamente com esses indicadores:

1. RemoteServerWin: Um servidor de aplicação utilizando .NET Remoting que roda como aplicação do windows.
2. RemoteServerService: Um servidor de aplicação, também utilizando .NET Remoting que roda como serviço do windows.
3. RemoteServerSetup: Um instalador dos projetos anteriores.

Vamos entender o esquema abaixo numa proposta didática, porém bem próxima de uma arquitetura ideal:

No ínicio do processo temos um usuário utilizando o seu computador para fazer solicitações ao servidor web através de um navegador. O servidor web é responsável apenas pela apresentação e desenho da página web. Qualquer necessidade de processamento de regras de négocio deverá ser enviada ao servidor de negócio. A linha usuario-navegador-servidor web-servidor de negócio poderia ser subistituida por outras configurações: celular-servidor web-servidor de negócio, aplicativo windows-servidor de negócio, etc. O fato é que o servidor de negócio precisa está preparado para receber e responder a requisições remotas. Neste servidor estaria configurado o RemoteServer.NET para responder solicitações da camada de apresentação. Algumas vezes o servidor de aplicação precisaria acessar dados do banco de dados. Esse acesso, de acordo com padrões de projetos e arquitetura em camadas deveria ser através de DAO´s. Logo poderiamos ter um servidor DAO para responder requisições feitas pelo servidor de negócio. Neste servidor DAO também teria instalado o RemoteServer.NET para responder requisições remotas. Por fim, temos uma máquina como servidor de banco de dados para acesso a dados.

As possibilidades são inúmeras. Imagine um enorme volume de usuários fazendo acesso ao servidor de regra. Poderiamos colocar novos servidores de negócio pra dividir a carga ou mesmo, mais servidores de acesso a dados fazendo com que as requisições fossem aleatórias a estes servidores evitanto o engarrafamento de requisições no mesmo servidor. Poderiamos também fazer replicação sincrona de dados no banco ou mesmo, utilização de cluster para dividir a carga de acesso ao banco de dados. Tudo dependendo do potencial do parque de informática da empresa e necessidade de acesso rápido ás informações. Adicionemos a tudo isso uma dose de XML Web Service para que outra aplicações possam conectar-se diretamente a seu servidor de regras via web.

As aplicações que voce desenvolve suporta essas possibilidades?  Isso é ESCALABILIDADE.

Na nossa página de Sistemas c/ Fontes estamos disponbilizando a solução RemoteServer.NET para aqueles que desejarem adquirir e ampliar seus horizontes. Vale lembrar que o RemoteServer.NET sozinho não faz milagre. A aplicação como um todo deve ser pensada para suportar esses requisitos. O primeiro passo é repensar seus conceitos em desenvolvimento e pesquisar soluções que sejam multi-utilizáveis.

Quem desejar adiquirir esse e outros produtos entre em contato. Teremos o maior prazer em responder. Voce estará contribuindo para manter nossas pesquisas bem como, a qualidade das nossas publicações.

É isso.