Em primeir�ssimo lugar gostaria de agradecer a todos irm�os Javaneses pela ajuda da minha "D�vida cruel", bom estou enviando um .doc com alguns coment�rios a favor do cen�rio 1 e do cen�rio 2 e um desenho puramente ilustrativo, n�o estou usando UML at� pq n�o tenho nada definido. Faltou com certeza maiores detalhes sobre a aplica��o. Estou enviando algumas considera��es sobre essa "sopa de letrinha".
Cen�rio da aplica��o : Aplica��o N�O SER� DISTRIBUIDA ela ir� se comunicar com outro m�dulo q estar�, com certeza na mesma m�quina. Esse m�dulo ir� solicitar, atrav�s de par�metros, a minha aplica��o uma resposta pesquisada em arquivos xml. Basicamente � isso !!! ---> Ent�o o Pq de N�O usar uma arquitetura em Socket / RMI / CORBA ? - Essa aplica��o deve ser multithread, a� "esbarramos" no problema dos threads serem DEPENDENTES de plataforma o q me obrigaria escrever um c�digo, no tocante do thread, espec�fico para Rwindows ou para Unix(Linux), j� come�aria mal o projeto. - Deveria escrever um "CLIENTE" para colocar do lado do outro m�dulo q vai chamar a minha aplica��o, problema grave neste t�pico, o outro m�dulo vai ser escrito em VB/ASP e como minha aplica��o vai estar em JAVA, claro, seguindo Socket / RMI / CORBA a "coisa" deve come�ar a ficar enrolada al�m da tal "colcha-de-retalhos". - At� onde sei Socket / RMI / CORBA s�o arquiteturas poderosas, bonitas, e totalmente indicada em aplica��es DISTRIBUIDAS(N�o � o meu caso) ---> Pq usar uma arquitetura Servlet ? - Ela j� � "batizada" como multithread, a pr�pria API / Container onde vou rodar meu Servlet se encarrega de "dar o seu jeito" nos ambientes Rwindows e Unix, com isso nem me preocupo com problemas de round-robin / preemp��o dos ambientes, s� a� ganho em performace e portabilidade. - Eu faria uma camada "HTTP" caso o outro m�dulo fosse escrito em VB/ASP, nesse caso a performace iria cair, concordo, mas essa queda n�o seria t�o abrupta comparando-se ao esfor�o para adaptar uma aplica��o Java feita com Socket/RMI/CORBA para um m�dulo feito em VB/ASP, pelo menos teria um m�dulo "port�vel" - Teria a facilidade/velocidade de construir um Servlet q teria classes(Beans, n�o confundir com EJB) q seriam especialistas em pesquizar em diversas fontes de dados, ex: Conte�do XML, SOAP, BD. E o Servlet APENAS faria a comunica��o(bate-papo) com o m�dulo escrito em linguagens da MicroBomba !!! <<A favor e contra Servlet e Socket.doc>> Edson CARVAlho > O/ > /| > / \ Int� ! > >
A favor e contra Servlet e Socket.doc
Description: MS-Word document
