perl-oak-discuss-br Mailing List for Perl Oak

Ol=E1,

Vamos l=E1... pensando mais um cen=E1rio de uso, desta vez com PDA. Como
falei no outro email, o que vai identificar o PDA =E9 a intermit=EAncia n=
o
acesso =E0 rede e restri=E7=F5es extremas de hardware.

Para ajudar a pensar, pensamos um cen=E1rio simples de um vendedor
utilizando um PDA para lan=E7ar pedidos.

Algumas caracter=EDsticas t=E9cnicas devem ser respeitadas:
1) O sistema deve ser atualizado automaticamente.
2) M=F3dulos devem ser disponibilizados de acordo com as credenciais de
autentica=E7=E3o do usu=E1rio.
3) O sistema n=E3o pode depender de conex=E3o =E0 rede para operar.
4) A plataforma n=E3o pode depender de daemons ativos, uma vez que o
sistema operacional do PDA pode ser mono-tarefa.

A proposta que conseguimos elaborar (izut++) =E9 a que est=E1 no diagrama=
 em
anexo.

daniel

Em Qui, 2006-07-06 =E0s 17:22 -0300, Daniel Ruoso escreveu:
> "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos
> atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1rio=
 em um ou
> mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente?=
"

Depois de algum debate (izut++), conseguimos chegar a uma proposta para
essa interface.

A solu=E7=E3o teve como inspira=E7=E3o basicamente a id=E9ia de screen-wi=
de menus
do mezzo (symphonyos), e da proposta de portais em si (tomando como
exemplo a p=E1gina inicial do google), al=E9m da interface do iPod.

No entanto, simplesmente exibir portlets n=E3o =E9 suficiente para ser
considerado como ambiente de trabalho, primeiro por que existe a
limita=E7=E3o de um n=FAmero de portlets que =E9 razo=E1vel exibir em uma=
 p=E1gina,
e segundo por que ter portlets que o usu=E1rio raramente usa seria um
desperd=EDcio e um preju=EDzo =E0 usabilidade.

Neste ponto encontramos dois desafios:
1) Como lidar com a quest=E3o de exibir um n=FAmero maior de portlets sem
precisar ter muitos portlets ao mesmo tempo?
2) Como lidar com portlets que s=F3 s=E3o utilizados esporadicamente e qu=
e
n=E3o mere=E7am estar em exibi=E7=E3o?

Para o primeiro desafio, novamente inspirado pelo mezzo vimos que seria
poss=EDvel um usu=E1rio ter v=E1rios portais (que, coloquialmente chamamo=
s de
"mesa"), onde ele poderia distribuir portlets =E0 sua maneira. Um portlet
especial, provido pela plataforma permitiria a navega=E7=E3o entre esses
portais, o portlet "Meus Portais".

Para o segundo desafio, pensando na interface do iPod, pensamos que
seria poss=EDvel criar menus n=E3o hierarquizados que voc=EA acessa
progressivamente. Ent=E3o existiriam portlets de menu, que exibiriam
outros portlets sem que esses portlets tivessem que ser necessariamente
adicionados a nenhuma mesa. Mas que depois de visualizados, o usu=E1rio
poderia adicionar aquele portlet a uma mesa existente ou criar uma nova
mesa/portal para alocar aquele portlet dentro.

E por fim, para resolver a quest=E3o de que os m=F3dulos seriam
disponibilizados de acordo com as credenciais de autentica=E7=E3o, pensam=
os
em uma "mesa de menu", ou "Portal de Menu", que agruparia portlets de
menu de acordo com a categoriza=E7=E3o dos itens, permitindo que essa lis=
ta
fosse constru=EDda dinamicamente.

Desenhei um diagrama (em anexo) que ilustra como isso apareceria para o
usu=E1rio.

daniel

Em Qui, 2006-07-06 =E0s 19:48 -0300, Igor Sutton Lopes escreveu:
> Geralmente =E9 muito mais complicado voc=EA fazer com uma GUI o que voc=
=EA faz com um
> interpretador HTML decente. Se voc=EA utilizar a mesma tecnologia para =
o cliente,
> na minha opini=E3o =E9 melhor.

Nesse caso, para a discuss=E3o da caracter=EDstica em quest=E3o, tanto fa=
z se
=E9 implementado com GTKHTML ou com ncurses... O que importa =E9 que a
esta=E7=E3o tem que ser atualizada e deve ter novas aplica=E7=F5es instal=
adas
automaticamente e n=E3o pode depender da rede sempre dispon=EDvel, voc=EA=
 pode
utilizar janelas de conex=E3o para troca de informa=E7=F5es e para essa
atualiza=E7=E3o...

daniel

Em Qui, 2006-07-06 =E0s 19:39 -0300, Igor Sutton Lopes escreveu:
> Creio que temos condi=E7=F5es de tornar isso transparente. A aplica=E7=E3=
o cliente
> (seja ela GUI, Web, ou outra m=EDdia qualquer) entrar=E1 em contato com=
 o servi=E7o
> de localiza=E7=E3o de aplica=E7=F5es. Ele identificar=E1 o tipo de m=ED=
dia utilizada, e
> disponibilizar=E1 as informa=E7=F5es necess=E1rias para o aplicativo cl=
iente
> acess=E1-los. O cliente ent=E3o se responsabilizar=E1 por contactar as =
aplica=E7=F5es,
> conforme informa=E7=F5es passadas.

Ok, correto, tecnicamente...=20

> Um =FAnico servi=E7o de autentica=E7=E3o seria suficiente para isso? Se=
r=E1 pensado em
> v=EDnculos de confian=E7a entre 'dom=EDnios' distintos? Em primeiro mom=
ento, um
> ponto =FAnico de autentica=E7=E3o/autoriza=E7=E3o parece suficiente.

V=EDnculos de confian=E7a entre dom=EDnios =E9 certamente algo relevante,=
 e
alguns mecanismos de autentica=E7=E3o possibilitam isso, como X509, por
exemplo...

> Ent=E3o, creio que teremos modelos para cada tipo de aplica=E7=E3o que =
queira se
> utilizar, e isso me lembra muito XSLT.

A quest=E3o n=E3o =E9 apenas de exibir uma mesma interface de formas
diferentes... (acho que cheguei ao ponto de confus=E3o)... A quest=E3o =E9=
 que
cada um desses p=FAblicos, cada uma dessas interfaces, pode at=E9 prover
funcionalidades que s=E3o exclusivas de cada um...

Por exemplo... Em uma interface Web (no sentido que me referi no outro
email) n=E3o faz sentido uma interface de digita=E7=E3o de nota fiscal, a=
ssim
como n=E3o faz sentido na interface GUI a forma de navega=E7=E3o entre as
informa=E7=F5es que normalmente o hypertexto prov=EA. Lembrando mais uma =
vez,
n=E3o =E9 uma quest=E3o da tecnologia a ser usada, voc=EA pode muito bem =
ter a
interface web implementada com active desktop e a interface gui
implementada com AJAX...

Ent=E3o voltamos a pergunta inicial: Como essa interface funcionaria? (no
sentido da intera=E7=E3o com o usu=E1rio, e n=E3o no sentido t=E9cnico) S=
e
f=F4ssemos fazer um prot=F3tipo, com que se pareceria?

daniel

Em Qui, 2006-07-06 =E0s 19:49 -0300, Igor Sutton Lopes escreveu:
> Mais uma d=FAvida: quais ser=E3o as m=EDdias clientes em potencial?
> - web
> - gui
> - pda

Sim. O foco do projeto nesse momento ser=E1 exatamente para esses tr=EAs
p=FAblicos, sendo:

Web: Entendido no sentido de portal, ou seja, no sentido de uma
interface que privilegia a obten=E7=E3o de informa=E7=F5es (podendo ser
implementado como o Mezzo, do SymphonyOs ou como um portal acessado por
um browser)

Gui: No sentido de favorecer a=E7=F5es operacionais, privilegiando a entr=
ada
de dados (podendo ser implementado como uma aplica=E7=E3o standalone ou c=
om
um mini-servidor-de-aplicacao e um rederizador html com AJAX)

Pda: Ambiente restrito com acesso a poucas informa=E7=F5es e poucas
intera=E7=F5es, normalmente com restri=E7=F5es no acesso =E0 rede e restr=
i=E7=F5es de
recurso de hardware.

(Podemos deixar a quest=E3o tecnol=F3gica para um segundo momento...)

daniel

Daniel Ruoso <da...@ru...> writes:

> Ol=E1,
>
> Uma quest=E3o que ainda est=E1 em aberto para mim =E9 a quest=E3o de como=
 prover
> um ambiente web integrado com um conjunto indefinido de composite
> applications. Formulando melhor (izut++):
>
> "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos
> atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1rio e=
m um ou
> mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente?"

Mais uma d=FAvida: quais ser=E3o as m=EDdias clientes em potencial?

- web
- gui
- pda?
- ????

Daniel Ruoso <da...@ru...> writes:

> Em Qui, 2006-07-06 =E0s 18:55 -0300, Igor Sutton Lopes escreveu:
>> Daniel Ruoso <da...@ru...> writes:
>> > Uma caracter=EDstica importante, heradada da computa=E7=E3o pervasiva =
=E9 a
>> > id=E9ia de que o usu=E1rio n=E3o deva precisar interagir a respeito da
>> > instala=E7=E3o de novas aplica=E7=F5es ou a disponibiliza=E7=E3o de no=
vas vers=F5es de
>> > aplica=E7=F5es existentes.
>> Em que situa=E7=F5es seriam necess=E1rias aplica=E7=F5es sendo utilizada=
s apenas no lado
>> cliente, sem intera=E7=E3o com um servidor de aplica=E7=F5es? Loca=E7=F5=
es remotas talvez?
>
> Loca=E7=F5es remotas s=E3o s=F3 o caso mais simples, mas insuficiencia ou=
 falha
> de rede s=E3o outro caso, otimiza=E7=E3o de uso tamb=E9m justificam...

Vamos listar ent=E3o:

- loca=E7=F5es remotas, com acesso a rede prec=E1rio;
- otimiza=E7=E3o de uso;
- toler=E2ncia a falhas de rede (sincroniza=E7=E3o de dados);

O que mais?

>
>> Uma id=E9ia que julgo interessante =E9 a utiliza=E7=E3o no lado cliente =
um
>> interpretador HTML, como o Gecko. Ele estaria acompanhado de um
>> 'mini-servidor-de-aplica=E7=F5es' instalado no cliente. A distribui=E7=
=E3o dos m=F3dulos
>> seria feito atrav=E9s de um pacote (similar ao WAR).
>
> N=E3o =E9 melhor fazer logo a aplica=E7=E3o? voc=EA teria um peso para ro=
dar um
> interpretador html quando tudo que voc=EA queria era exibir um formul=E1r=
io,
> que o sistema operacional faz nativamente. O que ganhamos com isso?

Geralmente =E9 muito mais complicado voc=EA fazer com uma GUI o que voc=EA =
faz com um
interpretador HTML decente. Se voc=EA utilizar a mesma tecnologia para o cl=
iente,
na minha opini=E3o =E9 melhor. Mais f=E1cil do que criar uma camada interme=
di=E1ria,
por exemplo. A n=E3o ser que o foco seja a utiliza=E7=E3o de computadores c=
om poucos
recursos. Se for este o caso, n=E3o podemos utilizar recursos avan=E7ados c=
omo
AJAX, sendo suficiente um interpretador HTML simples, como o GTKHTML.

Daniel Ruoso <da...@ru...> writes:

> Em Qui, 2006-07-06 =E0s 18:54 -0300, Igor Sutton Lopes escreveu:
>> Daniel Ruoso <da...@ru...> writes:
>> > "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos
>> > atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1ri=
o em um ou
>> > mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente=
?"
>> Uma pista sobre o modo de disponibiliza=E7=E3o seria um 'localizador de =
servi=E7os',
>> que seria o respons=E1vel pela disponibiliza=E7=E3o dos endere=E7os das
>> aplica=E7=F5es.
>
> Sim, mas isso =E9 parte da infraestrutura do servidor de aplica=E7=F5es, =
n=E3o
> da interface. A interface vai efetivamente localizar esses servi=E7os... a
> quest=E3o =E9 como vai ser a experi=EAncia do usu=E1rio em rela=E7=E3o a =
isso?

Creio que temos condi=E7=F5es de tornar isso transparente. A aplica=E7=E3o =
cliente
(seja ela GUI, Web, ou outra m=EDdia qualquer) entrar=E1 em contato com o s=
ervi=E7o
de localiza=E7=E3o de aplica=E7=F5es. Ele identificar=E1 o tipo de m=EDdia =
utilizada, e
disponibilizar=E1 as informa=E7=F5es necess=E1rias para o aplicativo cliente
acess=E1-los. O cliente ent=E3o se responsabilizar=E1 por contactar as apli=
ca=E7=F5es,
conforme informa=E7=F5es passadas.

>
>> > * Usu=E1rios an=F4nimos (sem credenciais) podem ter acesso a um conjun=
to de
>> > m=F3dulos tamb=E9m.
>> Creio que cada aplica=E7=E3o deva ser respons=E1vel pela autoriza=E7=E3o=
 do
>> usu=E1rio.
>
> A id=E9ia de ter a plataforma =E9 justamente prover um mecanismo onde ela
> possa simplesmente dizer "usu=E1rio X tem acesso a Y", "usu=E1rio an=F4ni=
mo
> tem acesso a Z" e tudo acontecer de forma autom=E1tica.
>
> A quest=E3o =E9 que autentica=E7=E3o =E9 uma coisa que n=E3o varia muito,=
 pra falar
> a verdade, a =FAnica coisa que varia s=E3o o formato das credenciais... a=
cho
> que o PAM do Unix e o JAAS do Java s=E3o um =F3timo exemplo de implementa=
=E7=E3o
> que pode ser seguido, no entanto, existe uma camada de aplica=E7=E3o que =
=E9
> quem faz o qu=EA. Ter um diret=F3rio integrado de autoriza=E7=E3o me pare=
ce uma
> boa id=E9ia.

Um =FAnico servi=E7o de autentica=E7=E3o seria suficiente para isso? Ser=E1=
 pensado em
v=EDnculos de confian=E7a entre 'dom=EDnios' distintos? Em primeiro momento=
, um
ponto =FAnico de autentica=E7=E3o/autoriza=E7=E3o parece suficiente.

[snip]

>
> A quest=E3o =E9 que se pararmos para pensar, vamos ver que, no mundo real,
> quem utiliza a aplica=E7=E3o GUI =E9 a equipe operacional, que precisa dar
> entrada nos sistemas de um grande volume de dados e que precisa de muita
> agilidade para isso. (apenas lembrando que, pensando dessa forma, uma
> aplica=E7=E3o AJAX =E9 uma aplica=E7=E3o GUI).

Certo, ent=E3o temos que pensar neste p=FAblico tamb=E9m.

>
> No entanto, normalmente o p=FAblico que vai acessar uma aplica=E7=E3o web=
 (no
> formato de um portal, talvez) normalmente precisa obter muito mais
> informa=E7=F5es do que lan=E7ar. Nesse sentido, =E9 preciso uma interface
> orientada a isso.
>

E neste p=FAblico tamb=E9m :)

Ent=E3o, creio que teremos modelos para cada tipo de aplica=E7=E3o que quei=
ra se
utilizar, e isso me lembra muito XSLT.

[snip]

Em Qui, 2006-07-06 =E0s 18:55 -0300, Igor Sutton Lopes escreveu:
> Daniel Ruoso <da...@ru...> writes:
> > Uma caracter=EDstica importante, heradada da computa=E7=E3o pervasiva=
 =E9 a
> > id=E9ia de que o usu=E1rio n=E3o deva precisar interagir a respeito d=
a
> > instala=E7=E3o de novas aplica=E7=F5es ou a disponibiliza=E7=E3o de n=
ovas vers=F5es de
> > aplica=E7=F5es existentes.
> Em que situa=E7=F5es seriam necess=E1rias aplica=E7=F5es sendo utilizad=
as apenas no lado
> cliente, sem intera=E7=E3o com um servidor de aplica=E7=F5es? Loca=E7=F5=
es remotas talvez?

Loca=E7=F5es remotas s=E3o s=F3 o caso mais simples, mas insuficiencia ou=
 falha
de rede s=E3o outro caso, otimiza=E7=E3o de uso tamb=E9m justificam...

> Uma id=E9ia que julgo interessante =E9 a utiliza=E7=E3o no lado cliente=
 um
> interpretador HTML, como o Gecko. Ele estaria acompanhado de um
> 'mini-servidor-de-aplica=E7=F5es' instalado no cliente. A distribui=E7=E3=
o dos m=F3dulos
> seria feito atrav=E9s de um pacote (similar ao WAR).

N=E3o =E9 melhor fazer logo a aplica=E7=E3o? voc=EA teria um peso para ro=
dar um
interpretador html quando tudo que voc=EA queria era exibir um formul=E1r=
io,
que o sistema operacional faz nativamente. O que ganhamos com isso?

daniel

Em Qui, 2006-07-06 =E0s 19:06 -0300, Daniel Ruoso escreveu:
> Em Qui, 2006-07-06 =E0s 18:54 -0300, Igor Sutton Lopes escreveu:
> > Existem alguns projetos como o Symphony OS que podem nos dar algumas
> > dicas, pois eliminam a utiliza=E7=E3o de menus, e disponibiliza as
> > informa=E7=F5es como se fosse um 'active desktop'.
> http://www.symphonyos.com/
> =C9 uma proposta interessante, merece investiga=E7=E3o...=20

Apenas para registro:
http://www.symphonyos.com/wiki/index.php/The_Mezzo_Desktop

Na verdade o que estava falando era do Mezzo, e n=E3o do Symphony. Tem um
"graypaper" sobre o mezzo nessa url a=ED... vai pra biblioteca tamb=E9m..=
.

daniel

Em Qui, 2006-07-06 =E0s 18:54 -0300, Igor Sutton Lopes escreveu:
> Daniel Ruoso <da...@ru...> writes:
> > "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtid=
os
> > atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1r=
io em um ou
> > mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerent=
e?"
> Uma pista sobre o modo de disponibiliza=E7=E3o seria um 'localizador de=
 servi=E7os',
> que seria o respons=E1vel pela disponibiliza=E7=E3o dos endere=E7os das
> aplica=E7=F5es.

Sim, mas isso =E9 parte da infraestrutura do servidor de aplica=E7=F5es, =
n=E3o
da interface. A interface vai efetivamente localizar esses servi=E7os... =
a
quest=E3o =E9 como vai ser a experi=EAncia do usu=E1rio em rela=E7=E3o a =
isso?

> > * Usu=E1rios an=F4nimos (sem credenciais) podem ter acesso a um conju=
nto de
> > m=F3dulos tamb=E9m.
> Creio que cada aplica=E7=E3o deva ser respons=E1vel pela autoriza=E7=E3=
o do
> usu=E1rio.

A id=E9ia de ter a plataforma =E9 justamente prover um mecanismo onde ela
possa simplesmente dizer "usu=E1rio X tem acesso a Y", "usu=E1rio an=F4ni=
mo
tem acesso a Z" e tudo acontecer de forma autom=E1tica.

A quest=E3o =E9 que autentica=E7=E3o =E9 uma coisa que n=E3o varia muito,=
 pra falar
a verdade, a =FAnica coisa que varia s=E3o o formato das credenciais... a=
cho
que o PAM do Unix e o JAAS do Java s=E3o um =F3timo exemplo de implementa=
=E7=E3o
que pode ser seguido, no entanto, existe uma camada de aplica=E7=E3o que =
=E9
quem faz o qu=EA. Ter um diret=F3rio integrado de autoriza=E7=E3o me pare=
ce uma
boa id=E9ia.

> > * O Usu=E1rio pode visualizar mais de uma informa=E7=E3o ao mesmo tem=
po
> > (portal e portlets s=E3o uma pista, mas como decidir o que aparece on=
de?).
> Isto n=E3o fa=E7o id=E9ia ainda.

Tem nos materiais que mandei :), mas de qualquer forma, o JBoss Portals
e o Apache Portals s=E3o bons exemplos.

> > * Em um ambiente GUI, isso seria facilmente resolvido com a constru=E7=
=E3o
> > din=E2mica de uma hierarquia de menus, uma vez que na interface GUI a
> > necessidade =E9 muito mais de entrada de informa=E7=F5es, enquanto a =
interface
> > Web tem como caracter=EDstica (pensando no usu=E1rio potencial de uma=
 e de
> > outra) a obten=E7=E3o de informa=E7=F5es, de forma que uma hierarquia=
 de menus =E9
> > sub-otimizada para esse fim.
> A principal quest=E3o =E9: queremos que as informa=E7=F5es exibidas par=
a uma aplica=E7=E3o
> se pare=E7a com uma GUI? Seria realmente sub-otimizada?

A quest=E3o =E9 que se pararmos para pensar, vamos ver que, no mundo real=
,
quem utiliza a aplica=E7=E3o GUI =E9 a equipe operacional, que precisa da=
r
entrada nos sistemas de um grande volume de dados e que precisa de muita
agilidade para isso. (apenas lembrando que, pensando dessa forma, uma
aplica=E7=E3o AJAX =E9 uma aplica=E7=E3o GUI).

No entanto, normalmente o p=FAblico que vai acessar uma aplica=E7=E3o web=
 (no
formato de um portal, talvez) normalmente precisa obter muito mais
informa=E7=F5es do que lan=E7ar. Nesse sentido, =E9 preciso uma interface
orientada a isso.

> Voc=EA tem em mente algo que considere satisfat=F3rio?

Na verdade ainda n=E3o... como eu disse, a pista que eu tenho =E9 o esque=
ma
de portais e portlets, mas ainda n=E3o sei direito como isso
funcionaria...

> Existem alguns projetos como o Symphony OS que podem nos dar algumas
> dicas, pois eliminam a utiliza=E7=E3o de menus, e disponibiliza as
> informa=E7=F5es como se fosse um 'active desktop'.

http://www.symphonyos.com/
=C9 uma proposta interessante, merece investiga=E7=E3o...=20

Uma pergunta que podemos nos fazer =E9: Quais as semelhan=E7as entre essa
proposta e um portal? Que solu=E7=F5es ela traz que normalmente n=E3o
encontramos em um portal?

daniel

Daniel Ruoso <da...@ru...> writes:

> Ol=E1,
>
> Uma caracter=EDstica importante, heradada da computa=E7=E3o pervasiva =E9=
 a
> id=E9ia de que o usu=E1rio n=E3o deva precisar interagir a respeito da
> instala=E7=E3o de novas aplica=E7=F5es ou a disponibiliza=E7=E3o de novas=
 vers=F5es de
> aplica=E7=F5es existentes.

Em que situa=E7=F5es seriam necess=E1rias aplica=E7=F5es sendo utilizadas a=
penas no lado
cliente, sem intera=E7=E3o com um servidor de aplica=E7=F5es? Loca=E7=F5es =
remotas talvez?

Uma id=E9ia que julgo interessante =E9 a utiliza=E7=E3o no lado cliente um
interpretador HTML, como o Gecko. Ele estaria acompanhado de um
'mini-servidor-de-aplica=E7=F5es' instalado no cliente. A distribui=E7=E3o =
dos m=F3dulos
seria feito atrav=E9s de um pacote (similar ao WAR).

Daniel Ruoso <da...@ru...> writes:

> Ol=E1,
>
> Uma quest=E3o que ainda est=E1 em aberto para mim =E9 a quest=E3o de como=
 prover
> um ambiente web integrado com um conjunto indefinido de composite
> applications. Formulando melhor (izut++):
>
> "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos
> atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1rio e=
m um ou
> mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente?"

Uma pista sobre o modo de disponibiliza=E7=E3o seria um 'localizador de ser=
vi=E7os',
que seria o respons=E1vel pela disponibiliza=E7=E3o dos endere=E7os das
aplica=E7=F5es.

>
> * Usu=E1rios an=F4nimos (sem credenciais) podem ter acesso a um conjunto =
de
> m=F3dulos tamb=E9m.

Creio que cada aplica=E7=E3o deva ser respons=E1vel pela autoriza=E7=E3o do
usu=E1rio.

> * O Usu=E1rio pode visualizar mais de uma informa=E7=E3o ao mesmo tempo
> (portal e portlets s=E3o uma pista, mas como decidir o que aparece onde?).

Isto n=E3o fa=E7o id=E9ia ainda.

> * Em um ambiente GUI, isso seria facilmente resolvido com a constru=E7=E3o
> din=E2mica de uma hierarquia de menus, uma vez que na interface GUI a
> necessidade =E9 muito mais de entrada de informa=E7=F5es, enquanto a inte=
rface
> Web tem como caracter=EDstica (pensando no usu=E1rio potencial de uma e de
> outra) a obten=E7=E3o de informa=E7=F5es, de forma que uma hierarquia de =
menus =E9
> sub-otimizada para esse fim.

A principal quest=E3o =E9: queremos que as informa=E7=F5es exibidas para um=
a aplica=E7=E3o
se pare=E7a com uma GUI? Seria realmente sub-otimizada? Voc=EA tem em mente=
 algo
que considere satisfat=F3rio? Existem alguns projetos como o Symphony OS que
podem nos dar algumas dicas, pois eliminam a utiliza=E7=E3o de menus, e
disponibiliza as informa=E7=F5es como se fosse um 'active desktop'.

>
> Como eu disse, essa quest=E3o est=E1 em aberto...
>
> daniel
>
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Perl-oak-discuss-br mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-oak-discuss-br
----------

Daniel Ruoso <da...@ru...> writes:

> Ol=E1,
>
> Uma caracter=EDstica importante, heradada da computa=E7=E3o pervasiva =E9=
 a
> id=E9ia de que o usu=E1rio n=E3o deva precisar interagir a respeito da
> instala=E7=E3o de novas aplica=E7=F5es ou a disponibiliza=E7=E3o de novas=
 vers=F5es de
> aplica=E7=F5es existentes.

Em que situa=E7=F5es seriam necess=E1rias aplica=E7=F5es sendo utilizadas a=
penas no lado
cliente, sem intera=E7=E3o com um servidor de aplica=E7=F5es? Loca=E7=F5es =
remotas talvez?

Uma id=E9ia que julgo interessante =E9 a utiliza=E7=E3o no lado cliente um
interpretador HTML, como o Gecko. Ele estaria acompanhado de um
'mini-servidor-de-aplica=E7=F5es' instalado no cliente. A distribui=E7=E3o =
dos m=F3dulos
seria feito atrav=E9s de um pacote (similar ao WAR).

Daniel Ruoso <da...@ru...> writes:

> Ol=E1,
>
> Uma quest=E3o que ainda est=E1 em aberto para mim =E9 a quest=E3o de como=
 prover
> um ambiente web integrado com um conjunto indefinido de composite
> applications. Formulando melhor (izut++):
>
> "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos
> atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1rio e=
m um ou
> mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente?"

Uma pista sobre o modo de disponibiliza=E7=E3o seria um 'localizador de ser=
vi=E7os',
que seria o respons=E1vel pela disponibiliza=E7=E3o dos endere=E7os das
aplica=E7=F5es.

>
> * Usu=E1rios an=F4nimos (sem credenciais) podem ter acesso a um conjunto =
de
> m=F3dulos tamb=E9m.

Creio que cada aplica=E7=E3o deva ser respons=E1vel pela autoriza=E7=E3o do
usu=E1rio.

> * O Usu=E1rio pode visualizar mais de uma informa=E7=E3o ao mesmo tempo
> (portal e portlets s=E3o uma pista, mas como decidir o que aparece onde?).

Isto n=E3o fa=E7o id=E9ia ainda.

> * Em um ambiente GUI, isso seria facilmente resolvido com a constru=E7=E3o
> din=E2mica de uma hierarquia de menus, uma vez que na interface GUI a
> necessidade =E9 muito mais de entrada de informa=E7=F5es, enquanto a inte=
rface
> Web tem como caracter=EDstica (pensando no usu=E1rio potencial de uma e de
> outra) a obten=E7=E3o de informa=E7=F5es, de forma que uma hierarquia de =
menus =E9
> sub-otimizada para esse fim.

A principal quest=E3o =E9: queremos que as informa=E7=F5es exibidas para um=
a aplica=E7=E3o
se pare=E7a com uma GUI? Seria realmente sub-otimizada? Voc=EA tem em mente=
 algo
que considere satisfat=F3rio? Existem alguns projetos como o Symphony OS que
podem nos dar algumas dicas, pois eliminam a utiliza=E7=E3o de menus, e
disponibiliza as informa=E7=F5es como se fosse um 'active desktop'.

>
> Como eu disse, essa quest=E3o est=E1 em aberto...
>
> daniel
>
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Perl-oak-discuss-br mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-oak-discuss-br

Daniel Ruoso <da...@ru...> writes:

> Ol=E1,
>
> Uma caracter=EDstica importante, heradada da computa=E7=E3o pervasiva =E9=
 a
> id=E9ia de que o usu=E1rio n=E3o deva precisar interagir a respeito da
> instala=E7=E3o de novas aplica=E7=F5es ou a disponibiliza=E7=E3o de novas=
 vers=F5es de
> aplica=E7=F5es existentes.

Em que situa=E7=F5es seriam necess=E1rias aplica=E7=F5es sendo utilizadas a=
penas no lado
cliente, sem intera=E7=E3o com um servidor de aplica=E7=F5es? Loca=E7=F5es =
remotas talvez?

Uma id=E9ia que julgo interessante =E9 a utiliza=E7=E3o no lado cliente um
interpretador HTML, como o Gecko. Ele estaria acompanhado de um
'mini-servidor-de-aplica=E7=F5es' instalado no cliente. A distribui=E7=E3o =
dos m=F3dulos
seria feito atrav=E9s de um pacote (similar ao WAR).

Daniel Ruoso <da...@ru...> writes:

> Ol=E1,
>
> Uma quest=E3o que ainda est=E1 em aberto para mim =E9 a quest=E3o de como=
 prover
> um ambiente web integrado com um conjunto indefinido de composite
> applications. Formulando melhor (izut++):
>
> "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos
> atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1rio e=
m um ou
> mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente?"

Uma pista sobre o modo de disponibiliza=E7=E3o seria um 'localizador de ser=
vi=E7os',
que seria o respons=E1vel pela disponibiliza=E7=E3o dos endere=E7os das
aplica=E7=F5es.

>
> * Usu=E1rios an=F4nimos (sem credenciais) podem ter acesso a um conjunto =
de
> m=F3dulos tamb=E9m.

Creio que cada aplica=E7=E3o deva ser respons=E1vel pela autoriza=E7=E3o do
usu=E1rio.

> * O Usu=E1rio pode visualizar mais de uma informa=E7=E3o ao mesmo tempo
> (portal e portlets s=E3o uma pista, mas como decidir o que aparece onde?).

Isto n=E3o fa=E7o id=E9ia ainda.

> * Em um ambiente GUI, isso seria facilmente resolvido com a constru=E7=E3o
> din=E2mica de uma hierarquia de menus, uma vez que na interface GUI a
> necessidade =E9 muito mais de entrada de informa=E7=F5es, enquanto a inte=
rface
> Web tem como caracter=EDstica (pensando no usu=E1rio potencial de uma e de
> outra) a obten=E7=E3o de informa=E7=F5es, de forma que uma hierarquia de =
menus =E9
> sub-otimizada para esse fim.

A principal quest=E3o =E9: queremos que as informa=E7=F5es exibidas para um=
a aplica=E7=E3o
se pare=E7a com uma GUI? Seria realmente sub-otimizada? Voc=EA tem em mente=
 algo
que considere satisfat=F3rio? Existem alguns projetos como o Symphony OS que
podem nos dar algumas dicas, pois eliminam a utiliza=E7=E3o de menus, e
disponibiliza as informa=E7=F5es como se fosse um 'active desktop'.

>
> Como eu disse, essa quest=E3o est=E1 em aberto...
>
> daniel
>
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Perl-oak-discuss-br mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-oak-discuss-br

Ol=E1,

Uma caracter=EDstica importante, heradada da computa=E7=E3o pervasiva =E9=
 a
id=E9ia de que o usu=E1rio n=E3o deva precisar interagir a respeito da
instala=E7=E3o de novas aplica=E7=F5es ou a disponibiliza=E7=E3o de novas=
 vers=F5es de
aplica=E7=F5es existentes.

No entanto, as novas aplica=E7=F5es ou vers=F5es n=E3o devem ser executad=
as sem
a certifica=E7=E3o (X509 somente?) de uma autoridade espec=EDfica (setor =
de TI
da empresa, por exemplo).

Pensando no mundo Perl, =E9 poss=EDvel pensar a partir do m=F3dulo lib::h=
ttp
(http://search.cpan.org/~gmpassos/lib-http-0.01/lib/lib/http.pm ). Um
poss=EDvel exemplo de uso seria:

use lib::certified::x509 trust =3D> "/etc/trusted_certifieds", path =3D>
"http://servidor.de.modulos/";

ou

use lib::certified::x509 trust =3D> "/etc/trusted_certifieds", path =3D>
"/caminho/para/modulos/inseguros/";

De forma que o primeiro caso, ele iria buscar os m=F3dulos na rede e no
segundo em uma pasta local. Caso o certificado n=E3o seja validado, os
m=F3dulos na pasta n=E3o ser=E3o carregados.

Deu pra entender?

daniel

Ol=E1,

Uma quest=E3o que ainda est=E1 em aberto para mim =E9 a quest=E3o de como=
 prover
um ambiente web integrado com um conjunto indefinido de composite
applications. Formulando melhor (izut++):

"Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos
atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1rio e=
m um ou
mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente?"

* Usu=E1rios an=F4nimos (sem credenciais) podem ter acesso a um conjunto =
de
m=F3dulos tamb=E9m.
* O Usu=E1rio pode visualizar mais de uma informa=E7=E3o ao mesmo tempo
(portal e portlets s=E3o uma pista, mas como decidir o que aparece onde?)=
.
* Em um ambiente GUI, isso seria facilmente resolvido com a constru=E7=E3=
o
din=E2mica de uma hierarquia de menus, uma vez que na interface GUI a
necessidade =E9 muito mais de entrada de informa=E7=F5es, enquanto a inte=
rface
Web tem como caracter=EDstica (pensando no usu=E1rio potencial de uma e d=
e
outra) a obten=E7=E3o de informa=E7=F5es, de forma que uma hierarquia de =
menus =E9
sub-otimizada para esse fim.

Como eu disse, essa quest=E3o est=E1 em aberto...

daniel

Mais uma vez aqui estou eu...

Precisamos tamb=E9m trabalhar algumas quest=F5es conceituais, tanto as qu=
e
j=E1 conhecemos quanto as que ainda iremos perceber. Uma quest=E3o
conceitual =E9 anterior a uma quest=E3o t=E9cnica, e por isso =E9 indepen=
dente
de implementa=E7=E3o.

Da mesma forma, vou abrir um diret=F3rio QuestoesConceituais e vamos
trabalhar com um thread por quest=E3o com prefixo [CONCEITO] no assunto.

daniel

Ol=E1 de novo mais uma vez...

Estou fazendo emails separados porque s=E3o assuntos separados mesmo...=20

Um outro aspecto da arquitetura s=E3o caracter=EDsticas t=E9cnicas que a =
gente
j=E1 sabe previamente que s=E3o nececess=E1rias, e que n=E3o precisam est=
ar
explicitadas nos cen=E1rios de uso.

Por exemplo, poder autenticar utilizando v=E1rias credenciais (ident,
kerberos, X509 etc) =E9 uma caracter=EDstica t=E9cnica que n=E3o precisa =
ser
listada nos cen=E1rios de uso se deixarmos sua necessidade expl=EDcita
previamente.

Dessa forma, vou abrir um outro diret=F3rio no CVS com o nome de
CaracteristicasTecnicas para documentarmos isso.

Como no caso dos cenarios, vamos trabalhar um thread para cada
caracter=EDstica utilizando o prefixo [CARACT] no assunto.

daniel

Ol=E1 de novo...

A =FAnica metodologia que eu conhe=E7o para pensar uma arquitetura de
software =E9 pensar os cen=E1rios de uso no qual o software seria utiliza=
do
para poder testar os conceitos que estivermos pensando.

Para facilitar o trabalho de documentar esses cen=E1rios, abri um espa=E7=
o
no CVS do perl-oak para esse trabalho de planejamento. Dentro dele j=E1
criei um diret=F3rio Cenarios onde podemos catalogar esses cenarios.

Quem quiser manipular diretamente no CVS, basta ter uma conta no
sourceforge que eu autorizo, caso contr=E1rio, estarei tentando consolida=
r
os cen=E1rios que discutirmos na lista nesse diret=F3rio.

Para visualiza=E7=E3o, mesmo quem n=E3o tiver CVS e coisa e tal, pode ser
atrav=E9s da Web, na URL abaixo...
http://perl-oak.cvs.sourceforge.net/perl-oak/Oak/Oak2-Planning/

Para facilitar a discuss=E3o, vamos abrir um thread novo para cada
proposta de cen=E1rio que lan=E7armos e incluir [CENARIO] no assunto, por
exemplo: "[CENARIO] Sistema de PDV em rede inst=E1vel". Depois cada um
desses cen=E1rios ter=E1 um arquivo no CVS com o seu formato (=E9 bom no =
CVS
porque teremos o hist=F3rico das modifica=E7=F5es no cenario)...

daniel

Beleza,

Vamos come=E7ar os trabalhos...

Acho que era legal come=E7ar com algumas leituras que eu fiz e que eu ach=
o
que seriam legais para a gente sintonizar as id=E9ias... Seria legal quem
tiver outras refer=EAncias de leitura poder passar tamb=E9m...

Especifica=E7=E3o da W3C para arquitetura de Web Services
http://www.w3.org/TR/ws-arch/

Especifica=E7=E3o da OASIS para arquitetura de Web Services para Portlets
Remotos
http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-=
01.html

Architectural Styles and
the Design of Network-based Software Architectures
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Web Services Context Service Specification
http://developers.sun.com/techtopics/webservices/wscaf/wsctx.pdf

Web Services Description Language (WSDL) 1.1
http://www.w3.org/TR/wsdl

Enterprise Services Architecture (Dan Woods)
ISBN: 0596005512

Packaged Composite Applications: An O'Reilly Field Guide to Enterprise
Software (Dan Woods)
ISBN: 0596005520

OASIS -- Web Services Coordination Framework Specification -- Web
Services Composite Application Framework
http://www.oasis-open.org/committees/documents.php?wg_abbrev=3Dws-caf


Daniel Ruoso