¿Programa en la nube? [Archivo]

newtron

15-07-2014, 10:53:16

Hola a tod@s.

Llevo observando de un tiempo a esta parte el tema de los programas "Saas" o "Cloud computing" o "programas en la nube" o como les quieran llamar.

Hasta ahora no me ha preocupado demasiado ese tema porque no están todavía muy extendidos y depende para qué sectores, yo en particular, no lo veo una buena solución, pero ahora (en España) están incentivandolos mucho con ayudas, subvenciones, etc. y ya si que empieza a preocuparme.

Mi pregunta es la siguiente: ¿hay alguna forma de un programa delphi "de escritorio" de toda la vida funcione en modo "cloud computing" o hay que hacer un programa nuevo?, ¿qué opinais sobre el tema?, ¿alguien tiene experiencia en este campo?.

Saludos

duilioisola

15-07-2014, 12:05:36

Si haces un programa de escritorio y lo pones dentro de un servidor con Terminal Service tendrás tu programa en la nube.

newtron

15-07-2014, 12:21:45

Si haces un programa de escritorio y lo pones dentro de un servidor con Terminal Service tendrás tu programa en la nube.

Ya pero el servicio de terminal server tiene un problema serio con el tema de las impresoras que si no está el driver instalado en el servidor no la captura y no puedes imprimir. No sé eso qué solución tendrá.

Gracias y un saludo

Neftali [Germán.Estévez]

15-07-2014, 13:41:49

¿hay alguna forma de un programa delphi "de escritorio" de toda la vida funcione en modo "cloud computing" o hay que hacer un programa nuevo?, ¿qué opinais sobre el tema?

Actualmente la única opción es tal y como han comentado utilizar Servicios de Terminal Server o Similares; Hay otras empresas que comercializan soluciones más baratas y similares, aunque no las he probado. Habría que ver cómo solventan el tema de las impresiones.

Sin reescribir la aplicación cvreo que no hay otra opción.

Si la aplicación puedes "pasarla" a FireMonkey sin grandes problemas, hay soluciones como esta (http://www.cybelesoft.com/webfmx/), que permiten acceder a ella mediante un navegador usando HTML5, pero sinceramente tengo serias dudas sobre el rendimiento. Habría que evaluarlo.
Échale un vistazo a las demos (https://webfmx.thinrdp.net/).

Luego está el tema de las aplicaciones tipo Web (de las que hablamos en este foro (http://www.clubdelphi.com/foros/forumdisplay.php?f=51)), tipo uniGui, Raudus, ExtPascal,... Pero no son directas. Implican reescribir la aplicación (al menos la parte visual).

No se me ocurren más...

duilioisola

15-07-2014, 14:59:47

Para el tema de impresoras, existen solcuiones. Una es utilizar Citrix. Otra es utilizar Thinprint.
Ambas de pago... pero también lo son las licencias de Terminal Service.

De todos modos, si es para una empresa a la que le montas el servidor, puedes montarle los drivers de las diferentes impresoras que tenga.

Al González

15-07-2014, 17:25:48

mamcx

15-07-2014, 17:31:13

Si haces un programa de escritorio y lo pones dentro de un servidor con Terminal Service tendrás tu programa en la nube.

Hay que estirar bastante el concepto de nube para usar un servicio de intranet/extranet como Terminal Service pa' decir que es la nube.

----

La "nube" es básicamente una forma de decir "Aplicaciones/Servicios n-tier interconectadas por protocolos de internet". Esto incluye no solo "paginas web" sino también las apps de dispositivos como iOS que de alguna manera utilizan un backend y/o otros servicios Saas (https://en.wikipedia.org/wiki/Software_as_a_service) y PAAS (https://en.wikipedia.org/wiki/Platform_as_a_service).

Aunque se puede argumentar que una paginita en PHP es la "nube", en la practica este concepto se entiende no solo como el usar tecnologías web, sino la FORMA como eso se usa, a un nivel estratégico & de implementación, al igual que su enfoque.

Algunos de los temas comunes en este tipo de apps:

- ES una app. NO una pagina ni un sitio web. -Aunque la app *puede* ser implementada con tecnologías asociadas con pagina y/o sitios web. Un ejemplo: Pinterest, Facebook. En cambio, el sitio web de una empresa no entraria en el concepto.

- Esta hecha para *escalar* bajo demanda. Si de pronto pasas de 10 a mil usuarios en *un dia* la app responde adecuadamente.

- NO necesariamente es una app para consumidores. Puede ser que ofrezcas un API, un PAAS, un SAAS o un BAAS o una combinación de todo esto. Por ejemplo, si haces un servicio con un API REST que genera documentos en PDF en base a datos que envias por JSON, CVS o similar

- Comúnmente, se construyen en parte o en totalidad sobre Amazon Web Services, Azure, Heroku y similares. Montarlo sobre el típico LAMP? Eso NO basta. Todo porque:

- Lograr la escalabilidad, flexibilidad y resilencia de una app en la nube requiere destrezas y tecnologias complementarias (o que reemplazan en su totalidad) al típico: 1 motor sql, un lenguaje de scripting, una pagina o app de escritorio. Esto incluye:

* Capacidad elastica de crear/destruir servidores, servicios de aplicaciones y similares bajo demanda (crear un servidor web y/o de base de datos y/o de apps y/o de dns y/o etc cuando se necesite)

* (Posiblemente) Uso de librerías de cacheo (ie: Redis)

* (Posiblemente) Uso de uno o mas engine NOSQL (ie: Redis, MongoDB, Cassandra)

* (Posiblemente) Uso de uno o mas engines de SQL (ie: Postgres, MySql, ...)

* Exponer un API. Esto es casi una marca definitoria de las apps en la nube. NO tiene que ser un api publica. Pero para orquestar todo la app 2-tier no es tan común, aunque sucede.

* Consumir 1 o mas servicios de SAAS, PAAS, BAAS, APARTE DE LOS QUE TU HAGAS. Es muy difícil armar todo esto, así que esto es una característica definitoria. Ejemplos: parse.com, Apple Push Service, Google Maps API, Azure Mobile Services, Heroku PostgreSql, Amazon S3, Google App Engine, Amazon Elastic Cloud, New Relic, etc

Lo mas popular para armar este tipo de soluciones es usar Python, Ruby, GO, Node, HTML5, iOS, Android, Redis, Mongo, Postgres, MySql, Cassandra, Couchdb, REST, JSON.

Delphi nunca se ve en el radar mas allá de foros como este y de lo que cuenta embarcadero, lo que implica que es mas esforzado hacer parte del ecosistema (de hecho creo que muchos ni saben que tal cosa llamada delphi existe. Lo que no tiene que ver con su popularidad, porque he visto gente usando erlang, elixir, scala, y muchos otros lenguajes de nicho y tecnologias raras que están mucho mejor situados que delphi. No ayuda lo costoso de su entrada y uso).

newtron

16-07-2014, 09:34:29

Hola Newtron.

Ya llevas algún tiempo en el mundo del desarrollo y, como sabes, todas las "tendencias" y "modas" informáticas hay que tomarlas con pinzas. Con esto no pretendo desacreditar a la famosa computación en la nube, pero sí creo que hay que irse con calma viendo cada caso en particular.

Primero es detectar, dentro de los usuarios actuales y potenciales de tu software, quiénes tienen o tendrán necesidad de acceder a la información de éste a través de Internet, mediante qué tipo de dispositivos, qué información en concreto deben poder ver y qué operaciones podrán realizar.

Una vez que hayas analizado lo anterior, te será más fácil determinar la solución a aplicar en cada caso concreto.

Me llaman a desayunar, buena suerte amigo.

Al.

En cierto modo llevas razón Al, el tema es que esto de la informática, como bien sabes, cambia mucho y muy rapidamente y puede pasar que si esta tendencia se consolida en el mercado y te pilla fuera de juego al final te quedas desfasado y la competencia te come.

Yo ahora mismo lo único que estoy es informándome de qué se mueve en ese mundo para poder decidir en un momento dado, si es necesario, embarcarnos en un desarrollo de ese tipo.

Por cierto... casi todo lo que habla el amigo mamcx me suena a chino, es posible que ya esté mayor para estas cosas.... :D

Gracias a todos y saludos

Casimiro Notevi

16-07-2014, 09:51:11

Analizando un poco todo esto de "Programa en la nube" en forma práctica, lógica y simplista es muy fácil de explicar, comprender y de hacer:
¿Recordáis cuando salió windows y nuestros programas eran para MSDOS?, pues bien, ¿cómo se solucionaba el problema de una empresa que quería estar "a la última"?, fácil:
Le ponías un servidor windows e instalabas el programa. En los PCs terminales se ponía un icono enlace al programa en el servidor windows.
Desde los PCs terminales se ejecutaba el programa que estaba en el servidor windows. Voilà, programas en la nube.

Ahora, en lugar de tener el servidor windows en la oficina, tenemos un servidor en cualquier lugar, por internet ("en la nube") y te conectas a él. Igual.

Es el mismo funcionamiento, no cambia nada, esto es como las modas, que vuelven de nuevo pasado un tiempo.

newtron

16-07-2014, 17:35:08

Es el mismo funcionamiento, no cambia nada, esto es como las modas, que vuelven de nuevo pasado un tiempo.

Pues a mi lo que me preocupa es que en vez de ser una moda sea una tendencia que se consolide y nos pille fuera de juego.

La verdad es que ese sistema de trabajo, depende para qué empresas, tiene sus ventajas. Sobre todo para empresas con varias delegaciones y que necesiten tener la información accesible desde cualquier lado. Si, terminal server es una solución, pero una solución que tiene mucho trabajo de instalación y configuración de terminales, impresoras, etc. Esto es otra historia, desde cualquier dispositivo que tenga conexión a internet accedes y trabajas.

mamcx

16-07-2014, 19:42:58

Pues a mi lo que me preocupa es que en vez de ser una moda sea una tendencia que se consolide y nos pille fuera de juego.

La nube ya es una industria multimillonaria y totalmente consolidada. A proposito, el que algo sea o no moda no lo vuelve una razón para disminuir su importancia. Al igual que en cualquier industria, la nuestra se mueve por tendencias y esa es la razón por la que no estamos programando mainframes en estos dias.

Aunque es cierto que se puede "maquillar" ciertas cosas de como se hacen antes y hacerlas llamar "nube", tal como apunta casimiro -y que dependiendo del contexto, en especial ante un cliente/colega ultradesinformado esperando que le digan los buzzwords del momento... puede ser necesario- no se debe ignorar que la nube tiene aspectos diferenciados del resto de apps/web tradicional.

Si estamos hablando de tendencias o paradigmas:

1- Era MS: Apps locales, departamentales, mono/multi-usuario tipicamente 1-2 tier, donde ser parte del desktop (lease: Windows) es lo mas característico y cada app/dato es una isla. Aqui domina C++, VB. Las app son fundamentalmente "event driven", se comunican a duras penas en una intranet, y se puede 100% usar un solo lenguaje para resolver todas las necesidades de desarrollo. Aqui Delphi es muy fuerte.

2- Era internet: Genera dinamicamente paginas web con ligera funcionalidad de app e interactividad. Aqui domina PHP/LAMP. Las app son fundamentalmente "stateless + POST/GET". Siguen siendo islas. Es posible 100% hacer todo esto en UN SOLO servidor. Usar 1.000 servidores? Eso solo lo hace un grandote como Google.

3- Era nube: Apps altamente distribuidas en N-Servidores -que no necesariamente estan bajo tu control, sino contratados-, elasticas, que interoperan mediante APIs, que estan hechas en N-lenguajes & plataformas, que tienen interfaces en N-plataformas (html5, ios, desktop, etc). Son principalmente apps "stateless + POST/GET + PUSH/PULL + Event-Driven + Reactive + NOSQL/SQL + Caches + APIs + ...".

Usar 1.000 servidores? Eso lo puede hacer CUALQUIERA con una tarjeta de credito, a costos infimos.

Aproximadamente cuanto le costaria a newtron tener 1.000 servidores ya, en este instante?

http://calculator.s3.amazonaws.com/index.html

US 20 * 1 hora
* Sin contar costos extras, solo las maquinas. Obvio esto se sube, pero hombre, US 20 * 1000 servidores?

-----
Asi que lo que separa a las apps "nube" de las demas, y que esta implicito en el concepto de la palabra "nube" es la *escala* de la infraestructura y lo "nebuloso" de determinar todos los componentes, lo altamente distribuido y (potencialmente) intercambiable, el alcance global, no es para apps de intranet.

Osea, es lo *mismo* que antes pero si lo "mismo" es un casa, la "nube" es una ciudad entera (ie: La nube se construye, obviamente, en base a todo la tecnologia y modelos anteriores).

SIN EMBARGO hay aspectos que son exclusivos/nuevos que surgen exclusivamente para resolver problemas de estas soluciones.

Por ejemplo, estas son tecnologias/servicios que tienen sentido en la nube:

http://www.docker.com/

http://aws.amazon.com/es/products/?nc1=f_cc

De estas, EC2 es lo unico medio-parecido al modelo de sitio web "normal". S3, Elastic Load Balancing, Elastic Block Store, DynamoDB, Redshift, ElastiCache, Route 53, Elastic MapReduce, Kinesis, Data Pipeline, etc... son el resultado de necesidades que surgen con el tipo de problemas que se enfrentan quienes hacen apps en la nube, y que antes eran practicamente innecesarios.

Casimiro Notevi

16-07-2014, 21:54:13

Mamcx, si descendemos de la nube y pisamos tierra firme, no somos google, facebook y ni siquiera meneme.net
Estamos hablando de una gestión de ventas, básicamente, para una empresa pequeña (de 1 a 50 empleados) que quieran trabajar en la oficina, en casa o en la calle mediante un portátil o una tableta.
Si recortamos todo ese maremagnum de siglas, nombres, paradigmas, lenguajes, sistemas, métodos, etc. que has nombrado (y que parece escrito para despistar :p), podemos reducirlo a algo mucho más básico:

¿Qué es lo más práctico, cómodo, ágil, económico y real para tener algo "similar" al antiguo servidor con un programa msdos al que se conectan desde otros pcs?

Por cierto, "solamente 20 $ hora" son: 14400 $ mensuales -> 172800 $ anuales. Eso no es para una empresita pequeña.

mamcx

16-07-2014, 22:26:47

Mamcx, si descendemos de la nube ...
Estamos hablando de una gestión de ventas, básicamente, para una empresa pequeña (de 1 a 50 empleados) que quieran trabajar en la oficina, en casa o en la calle mediante un portátil o una tableta.

En tal caso, el modelo no aplica. Es lo mismo decir que si una app monousuario cumple a satisfacción los requerimientos entonces para que hacerlo n-tier?

Al igual que todo proyecto, hay que saber dimensionar las cosas.

Con todo, es 100% factible usar un servicio que corre en la nube, aun si tu app es del tipo que describes. Por ejemplo, cuando usan google maps o geolocalizacion, aun siendo la app monousuario, Google maps esta en la nube, esto es, un efecto colateral es que ahora se puede acceder a muchos recursos que antes eran imposibles para un equipo pequeño.

Por ejemplo, para la app que estoy haciendo, que es tal cual como la describes, utilizo varios servicios en la nube, no por seguir una moda, sino porque es practico hacerlo.

Casimiro Notevi

16-07-2014, 22:32:35

Lo que quiero decir es que con tantos nombres, tecnicismos, etc. lo que haces es confundir a la gente, en lugar de ayudar a aclarar las cosas ;)

Al González

16-07-2014, 23:04:39

Al igual que todo proyecto, hay que saber dimensionar las cosas.
Ergo:
Primero es detectar, dentro de los usuarios actuales y potenciales de tu software, quiénes tienen o tendrán necesidad de acceder a la información de éste a través de Internet, mediante qué tipo de dispositivos, qué información en concreto deben poder ver y qué operaciones podrán realizar.

Una vez que hayas analizado lo anterior, te será más fácil determinar la solución a aplicar [...]

Saludos lógicos.

P.D. Que bueno que existe la computación en la nube, y que bueno que resulte tan útil en algunos casos. Puede que Newtron encuentre algún valor en ella para sus proyectos. :) ^\||/

nlsgarcia

16-07-2014, 23:41:54

Club Delphi,

...Analizando un poco todo esto de "Programa en la nube" en forma práctica, lógica y simplista es muy fácil de explicar, comprender y de hacer...

:rolleyes:

Esto resume el concepto de Cloud Computing:

Cloud computing is the delivery of computing as a service rather than a product, whereby shared resources, software, and information are provided to computers and other devices as a utility (like the electricity grid) over a network (typically the Internet).

Tomado de : Wikipedia - Cloud computing (http://en.wikipedia.org/wiki/Cloud_computing)

Otra perspectiva del concepto de Cloud Computing:

...Asi que lo que separa a las apps "nube" de las demás, y que esta implícito en el concepto de la palabra "nube" es la *escala* de la infraestructura y lo "nebuloso" de determinar todos los componentes, lo altamente distribuido y (potencialmente) intercambiable, el alcance global, no es para apps de intranet...Esta hecha para *escalar* bajo demanda...Lograr la escalabilidad, flexibilidad y resiliencia...

^\||/

...a mi lo que me preocupa es que en vez de ser una moda sea una tendencia que se consolide...

Ciertamente no es una moda y a futuro se hará más común su uso por pequeñas y medianas empresas que quieran abaratar sus costos de TI.

...Lo que quiero decir es que con tantos nombres, tecnicismos, etc. lo que haces es confundir a la gente, en lugar de ayudar a aclarar las cosas...

Creo que los conceptos son importantes en toda área de conocimiento y en este caso particular hay una curva de aprendizaje a superar para la comprensión cabal del concepto de Cloud Computing, por lo cual se hacen necesarios dichos conceptos y tecnicismos :rolleyes:

...¿Qué es lo más práctico, cómodo, ágil, económico y real para tener algo "similar" al antiguo servidor con un programa msdos al que se conectan desde otros pcs?...

En mi opinión personal, el Cloud Computing será a futuro la solución simplista para pequeñas y medianas empresas y una opción importante dentro los recursos de TI de las grandes empresas :rolleyes:

Nelson.

Casimiro Notevi

17-07-2014, 00:27:18

Creo que los conceptos son importantes en toda área de conocimiento y en este caso particular hay una curva de aprendizaje a superar para la comprensión cabal del concepto de Cloud Computing, por lo cual se hacen necesarios dichos conceptos y tecnicismos

Es que newtron no lo pregunta como programador, sino como gerente de una empresa, además su pregunta es: ¿hay alguna forma de un programa delphi "de escritorio" de toda la vida funcione en modo "cloud computing" o hay que hacer un programa nuevo?

Y la respuesta de nuestro amigo mamcx incluye:

concepto de nube - servicio de intranet/extranet - Terminal Service - es la nube - Aplicaciones/Servicios n-tier interconectadas por protocolos de internet - paginas web - apps de dispositivos - iOS - backend - otros servicios Saas - PAAS - PHP es la "nube" - usar tecnologías web - FORMA como eso se usa - nivel estratégico & de implementación - enfoque - tipo de apps - NO una pagina ni un sitio web. - Aunque app *puede* ser implementada con tecnologías asociadas con pagina y/o sitios web. - Pinterest, Facebook - sitio web de empresa - *escalar* bajo demanda - pasas de 10 a mil usuarios en *un dia* - app para consumidores - ofrezcas un API - un PAAS - un SAAS o un BAAS - una combinación de todo esto - servicio con API REST - genera PDF en base a datos - envias por JSON, CVS o similar - construyen Amazon Web Services - Azure - Heroku y similares - Montarlo sobre LAMP? - NO basta. porque -- Lograr la escalabilidad - flexibilidad - resilencia de una app en la nube - requiere destrezas y tecnologias complementarias - reemplazan en totalidad típico: 1 motor sql, un lenguaje de scripting, una pagina o app de escritorio - Incluye Capacidad elastica de crear/destruir servidores, servicios de aplicaciones y similares bajo demanda (crear un servidor web y/o de base de datos y/o de apps y/o de dns y/o etc cuando se necesite - librerías de cacheo (ie: Redis) - mas engine NOSQL (ie: Redis, MongoDB, Cassandra) - uno o mas engines de SQL (ie: Postgres, MySql, ...) - Exponer un API - casi marca definitoria de apps en la nube - NO api publica - orquestar todo la app 2-tier no es común, aunque sucede - Consumir 1 o mas servicios de SAAS, PAAS, BAAS, APARTE DE LOS QUE TU HAGAS - muy difícil armar todo esto - esto es característica definitoria - parse.com, Apple Push Service, Google Maps API, Azure Mobile Services, Heroku PostgreSql, Amazon S3, Google App Engine, Amazon Elastic Cloud, New Relic, - popular para soluciones es Python, Ruby, GO, Node, HTML5, iOS, Android, Redis, Mongo, Postgres, MySql, Cassandra, Couchdb, REST, JSON - Delphi embarcadero - implica que es mas esforzado hacer ecosistema - usando erlang, elixir, scala, y muchos otros lenguajes de nicho y tecnologias raras mucho mejor situados que delphi - No ayuda lo costoso de su entrada y uso)

Ahí incluye todo, así no es difícil equivocarse, es como el hombre del tiempo: "mañana será un día soleado, aunque pueden aparecer nubes de evolución que dejen caer lluvia". Al final te quedas igual que al principio, sin saber si hará sol o si tienes que llevar el paraguas.

mamcx

17-07-2014, 00:29:22

Lo que quiero decir es que con tantos nombres, tecnicismos, etc. lo que haces es confundir a la gente, en lugar de ayudar a aclarar las cosas ;)

Y acaso eso no es la educacion? Primero te confunden, y luego pasas el resto de la vida estudiando pa' entender que fue todo eso!

----

Lo que pasa con los tecnicismos es que trato de dar terminos y servicios concretos que definen este tema. Es como decir "Que es todo eso de la OO?" y no hablar de herencia, polimorfismo, etc.. Aunque es bueno simplificar el asunto a una frase o 2, sin dar una idea de la dimension... se puede entender mal la cosa y pensar que hay que ir en otra direccion.

newtron

17-07-2014, 08:42:38

Pues....¿sabéis?... cada vez estoy más liado con el asunto.

Mi inquietud es saber si a una "mierdaempresa" como la mía le sería factible abordar de alguna manera el desarrollo de una aplicación de ese tipo o está fuera de mi alcance.

Neftali [Germán.Estévez]

17-07-2014, 10:07:59

Pues....¿sabéis?... cada vez estoy más liado con el asunto.
:D:D

Volviendo a la pregunta...

¿hay alguna forma de un programa delphi "de escritorio" de toda la vida funcione en modo "cloud computing" o hay que hacer un programa nuevo?, ¿qué opinais sobre el tema?, ¿alguien tiene experiencia en este campo?.

Intentando concretar, tal vez tendrías que explicar un poco mejor qué es para ti, o a qué necesidades te refieres con que: "el programa funcione en modo Cloud computing".
Como ya hemos visto, el concepto de "programación en la nube" incluye muuuuuuuchos conceptos y no todo el mundo los necesita todos (más bien al contrario).
Podríamos concretar el escenario que necesitas, y así ver posibles soluciones (o modificaciones mínimas) para que "ese mismo programa de escritorio" (condición única que has puesto) pueda funcionar en ese nuevo escenario.

=> Lo digo por que no es la primera empresa ni la última (incluyendo la mía) que se va a encontrar con situaciones similares.
(1) Proyecto grande (escritorio)
(2) Sin presupuesto ni personal para realizarlo "de nuevo" desde cero.
(3) Con necesidad de cambio de escenario.

engranaje

17-07-2014, 10:13:36

Según lo leido anteriormente lo que voi a decir no tiene nada que ver con la nube. Tengo una antigua aplicación desarrollada en delphi 2.0 y sobre la que aún tengo que ir haciendo modificaciones de vez en cuando y con la que tuve que adaptarme a los nuevos tiempos. Al final está montada en un servidor citrix. El usuario final solo sabe que tiene que descargar el plugin de citrix para su navegador web, escribir la url que le paso, poner su usuario y contraseña y utilizar la aplicación de escritorio que desee de las que tiene publicadas.

Es cierto que básicamente no es distinto de conectarse mediante la red local al servidor de aplicaciones de la oficina. Pero la sensación que da al usuario final sin demasiados conocimientos se parece bastante. Aún con los quebraderos de cabeza lógicos el proceso no supuso el esfuerzo que habría supuesto realizar la aplicación de nuevo.

Casimiro Notevi

17-07-2014, 10:16:27

Primero de todo, como siempre, es coger papel y lápiz y escribir lo que se quiere conseguir, las distintas opciones que podrían ser factibles y luego ver los pros y contras de cada una para escoger a la más idónea para tus necesidades.

(1) Lo más simple es poder usar los programas actuales que tienes (delphi) en windows corriendo sobre un servidor linux. De esa manera puedes aprovechar para tener varios windows al mismo tiempo en un mismo servidor, ahorrando costes de hardware. Siendo fácil añadir más servidores con más clones windows con los programas delphi.
Los clientes, he aquí el problema, tendrían que ejecutar algo similar a "terminal server", algún otro programa VNC o incluso hace años existía un "terminal server" libre y gratis que funcionaba muy bien, era más ágil que el "original" y no tenía problema con las impresoras. El problema es que le perdí la pista hará unos ocho o diez años, pero supongo que existirá algo similar o mejor.
Esta opción obliga a los usuarios usar pcs, portátiles o tabletas con windows.

(2) Si se quiere que el usuario pueda usar "lo que quiera", ya sea windows, android o iOS, entonces no vale, principalmente por la impresora, aunque hay posibilidades distintas, como por ejemplo: que los listados no se envien directamente a una impresora, sino a un documento PDF, ese documento PDF es enviado al usuario e independientemente del sistema que tenga (windows, android, etc.) se imprime porque es un pdf. (O sea, no enviar documento a impresora, sino a PDF y enviar el PDF al usuario. El usuario lo imprime como quiera y con lo que quiera y pueda)

Las otras opciones pasan por hacer nuevos programas, así que de momento creo que no es lo que estás buscando.

Creo que la opción (2) puede ser bastante factible, habría que investigar un poco, pero así sin darle muchas vueltas a la cabeza, puede ser factible.

Casimiro Notevi

17-07-2014, 10:31:05

je, je... 3 respuestas en menos de 10 minutos.

La opción citrix tiene varios inconvenientes, pero el principal es el precio, creo que newtron, aunque no lo ha especificado (realmente no ha especificado nada :p ), está pensando en el menor gasto posible añadido para él y sus clientes, sería un sobrecoste más, que tal y como están las cosas... :(
La opción terminal server tiene el mismo inconveniente, otro gasto añadido, aunque también tiene la obligatoriedad de usar windows, cosa que es peor. Al menos con citrix tiene un abanico mayor de posibilidades.

Yo me decantaría (previo análisis, investigación, estudio, etc. etc. etc.) por crear una máquina virtualbox, por ejemplo, básica de winXP, eliminando todo lo innecesario, dejándola en la mínima expresión posible, y la tendría como "plantilla" para todas las nuevas que se vayan necesitando.
Esas máquinas virtuales winXP correrían sobre un servidor linux con una buena cantidad de memoria ram (para ejecutar la mayor cantidad posible de esos clones winXP). Por cpu no hay que preocuparse hoy en día.
Habría que calcular qué memoria usa la gestión actual de newtron, pero casi seguro que con 1 giga va más que sobrado, así que con un equipo ubuntu server, debian o similar con, por ejemplo 8 gigas de ram y una cpu de 6 u 8 cores, puedes ejecutar tranquilamente y totalmente sobrado, al menos 6 máquinas virtuales (dejando 2 gigas para linux), de sobra para la mayoría de pequeñas empresas. Con 16 gigas de ram ya abarcaría 14 máquinas virtuales. Y si hace falta se añade otro servidor y... hasta el infinito :p

Evidentemente, todos estos son números a lo bruto, habría que probar, investigar, afinar, etc.

Al González

17-07-2014, 18:07:00

je, je... 3 respuestas en menos de 10 minutos.
Como en los viejos tiempos, señor Veintidós mil (o Casi). ;) v:-)v

mamcx

17-07-2014, 19:29:11

Pues....¿sabéis?... cada vez estoy más liado con el asunto.

Mi inquietud es saber si a una empresa como la mía le sería factible abordar de alguna manera el desarrollo de una aplicación de ese tipo o está fuera de mi alcance.

Lo que se perdio entre todo lo que escribí... es que ahora es *trivial* usar el cloud a un costo infimo (o gratuito!) no solo para empresas minúsculas sino para individuos.

Y esto aplica tanto a la hora de desarrollar como a la hora de usar.

Como puse en http://clubdelphi.com/foros/showthread.php?t=86291 la cantidad de recursos disponibles ahora son tantos, que el problema es saber que escoger!

----

Retomando la pregunta " Que hay que hacer para, usando Delphi (y lo que sea) usar la nube?". A nivel tecnico? Casi siempre es cuestion de inscribirse/contratar algun servicio de los mencionados y hacer llamadas a API mediante HTTP y/o usar algun SDK.

Para cosas pequeñas los costos son 0 o muy bajos. Por ejemplo, mis sitios web los monto en http://heroku.com/ y no me cuesta nada.

Tambien puedes obtener 1 año gratis con Amazon y con Azure, junto a http://www.microsoft.com/bizspark/default.aspx que te dan 3 años de licencias de MS, Azure y todo al final pagas como US 200 o algo asi.

Basicamente, todo se reduce a pensar que quieres o necesitas, y mirar si ya hay un servicio que lo resuelve.

Te pongo un ejemplo. Digamos que quieres mandar mensajes de texto a cualquier celular, pero no quieres (como toda persona sana) negociar con cada operador de cada pais.

Entonces usas https://www.twilio.com/. Lees los docs en https://www.twilio.com/docs/api. miras si hay un SDK en tu lenguaje y sino es pan comido, usas llamadas REST y resuelves el problema en menos de 2 dias (lo que generalmente toma hacer un cliente REST).

Asi que si tienes algun tema *concreto* en mente, es solo que preguntes, seguro que tengo por ahi un link a algo que te ayude ;)

En ultimas? Esto no es tan dificil... de hecho es *trivial* para cosas pequeñas. Solo se puede poner interesante si tu app empieza a escalar de alguna manera.

Ñuño Martínez

24-07-2014, 17:56:20

Cuando oí hablar por primera vez de la "Computación en la Nube" pensé:
Genial: han cogido un concepto más viejo que la pana, le han puesto un nombre nuevo y a venderlo como si fuera lo último de lo último. Otra vez.
Y lo sigo manteniendo. Todavía no veo qué diferencia hay entre la "Computación en la Nube" que nos venden ahora y la "Computación Distribuida" de toda la vida.

nlsgarcia

24-07-2014, 19:44:18

Ñuño Martínez,

...Todavía no veo qué diferencia hay entre la "Computación en la Nube" que nos venden ahora y la "Computación Distribuida" de toda la vida...

:rolleyes:

Cloud computing is the delivery of computing as a service rather than a product, whereby shared resources, software, and information are provided to computers and other devices as a utility (like the electricity grid) over a network (typically the Internet)

Tomado de: Cloud computing (http://en.wikipedia.org/wiki/Cloud_computing)

...A distributed system is a software system in which components located on networked computers communicate and coordinate their actions by passing messages. The components interact with each other in order to achieve a common goal...Distributed computing also refers to the use of distributed systems to solve computational problems. In distributed computing, a problem is divided into many tasks, each of which is solved by one or more computers, which communicate with each other by message passing.

Tomado de: Distributed computing (http://en.wikipedia.org/wiki/Distributed_computing)

Te comento:

1- En Cloud Computing todos los recursos disponibles son ofrecidos como servicios (IaaS, PaaS, SaaS), los cuales pueden hacer o no uso de computación distribuida para su implementación.

2- En Computación Distribuida el objetivo es la unificación coordinada de recursos de computación distribuidos en una red para la ejecución y resolución de problemas de forma conjunta, no incluye en su concepción la idea de servicios ni virtualización.

3- Cloud Computing es una clase de Grid Computing (Una forma de computación distribuida) y su principal tecnología es la virtualización (http://en.wikipedia.org/wiki/Virtualization).

En Resumen: A pesar de ser conceptos que tienen puntos en común en lo que a distribución de recursos se refiere, el concepto de Cloud Computing es más amplio e incluye más tecnologías, la idea principal que subyace en el modelo de Cloud Computing es : Servicios a un bajo costo de forma masiva, escalable y resiliente.

Espero sea útil :)

Nelson.

Casimiro Notevi

24-07-2014, 21:43:47

¿Resiliente? ¿eso qué es? :confused:

nlsgarcia

24-07-2014, 22:16:53

Casimiro,

...¿Resiliente?...

:rolleyes:

Revisa esta información:

Ability of an equipment, machine, or system to absorb the impact of the failure of one or more components or a significant disturbance in its environment, and to still continue to provide an acceptable level of service.

Tomado de : resilience (http://www.businessdictionary.com/definition/resilience.html)

En términos generales, es un concepto tomado de la ingeniería (http://en.wikipedia.org/wiki/Resilience) y aplicado a diversas áreas del conocimiento para denotar su grado de flexibilidad, adaptación y resistencia a problemas externos.

Espero sea útil :)

Nelson.

Casimiro Notevi

24-07-2014, 22:36:29

¡Ah!, elástico o flexible.

newtron

26-07-2014, 10:44:41

Hola a todos de nuevo.

Antes de nada pediros disculpas por este paréntesis de una semanita. He estado dedicado a cuatro cosas fundamentales (se me ocurre alguna más pero este es un foro público y puede haber menores :D): Playa, piscina, comer y beber, y por supuesto sin ningún dispositivo electrónico a mano.

Creo que el amigo Neftali ha resumido perfectamente mi problema, que parece que es un problema común.

La idea es que el cliente pulse en un iconito o llame a una página web, que se le pregunte un nombre de usuario y una clave y que acceda a su programa.

Como se apuntaba por ahí una posible solución sería montar el programa en un servidor y acceder mediante terminal server pero no lo veo una solución elegante para uso genérico por el problema de las impresoras, la idea es que el cliente esté donde esté y tenga la impresora que tenga pueda usar el programa sin mayores complicaciones. Yo tengo bastantes instalaciones de terminal server y van muy bien pero son clientes que están controlados por nosotros en hardware y software y procuramos dejarlo todo instalado y configurado.

Se habla de Citrix pero eso no sé ni lo que es, ¿alguien me lo explica como si yo fuera un niño?. :D

Saludos

mamcx

26-07-2014, 15:29:17

Si no necesitas la capacidad de distribución ultra-masiva del html/browser, no le veo un problema a hacer exactamente para escritorio tal cual como se hace en mobiles: Una app nativa que "habla" mediante protocolos de internet a un servidor (de BD y/o de app).

Si se quisiera hacer como una pagina web, se puede generar PDF. O se puede hacer un mini-cliente que se instala en la maquina (como un plugin) que tenga la capacidad embeida de responder a llamadas http/websocket y que desde js se invoke para el control de impresoras y demas.

nlsgarcia

26-07-2014, 17:11:10

newtron,

...Se habla de Citrix pero eso no sé ni lo que es, ¿alguien me lo explica como si yo fuera un niño?...
:rolleyes:

Básicamente es una tecnología de virtualización de servidores, estaciones de trabajo y aplicaciones para su distribución en forma de servicios.

Revisa esta información:

1- Citrix Systems (http://es.wikipedia.org/wiki/Citrix_Systems)

2- Citrix (http://www.citrix.es/)
Espero sea útil :)

Nelson.

newtron

27-07-2014, 09:00:18

newtron,

:rolleyes:

Básicamente es una tecnología de virtualización de servidores, estaciones de trabajo y aplicaciones para su distribución en forma de servicios.

Revisa esta información:
Espero sea útil :)

Nelson.

Gracias, le echo un vistazo.

Si no necesitas la capacidad de distribución ultra-masiva del html/browser, no le veo un problema a hacer exactamente para escritorio tal cual como se hace en mobiles: Una app nativa que "habla" mediante protocolos de internet a un servidor (de BD y/o de app).

Si se quisiera hacer como una pagina web, se puede generar PDF. O se puede hacer un mini-cliente que se instala en la maquina (como un plugin) que tenga la capacidad embeida de responder a llamadas http/websocket y que desde js se invoke para el control de impresoras y demas.

Pero ahora yo pregunto... ¿si hay que instalar apps o clientes no se sale del concepto que estamos hablando?

mamcx

27-07-2014, 15:52:28

Ni la nube ni internet dicta que los clientes tienen que ser obligadamente html. El exito de las apps en móviles muestra eso. Y si el cuento es automatizar las actualizaciones de las apps, pues las mismas muestran como se hace (y hacer que una app de escritorio se mantenga al dia es trivial estos dias).

newtron

28-07-2014, 09:41:50

Bueno, entonces una posible solución sería descargar la aplicación en modo local y mantener la base de datos en la nube, ¿no?.

Tengo otra pregunta, ¿las aplicaciones que se usan en cualquier dispositivo o sistema operativo qué son, html o hay alguna otra forma?

Ñuño Martínez

28-07-2014, 12:53:49

Muchas gracias por la aclaración, Nelson. Por lo que veo, no estaba completamente en lo correcto al decir que son lo mismo, pero muy desacertado no andaba ya que, si no entendí mal, cloud computing es un subconjunto dentro de la computación distribuida.

¿Ahora sí?

nlsgarcia

28-07-2014, 16:55:19

Ñuño Martínez,

...cloud computing es un subconjunto dentro de la computación distribuida...

:rolleyes:

Cloud Computing es un Super Conjunto que incluye a la Computación Distribuida y otras tecnologías , la Computación Distribuida no incluye en su concepción la idea de servicios ni virtualización que son la base del concepto de Cloud Computing.

Espero sea útil :)

Nelson.

mamcx

28-07-2014, 17:25:11

Tengo otra pregunta, ¿las aplicaciones que se usan en cualquier dispositivo o sistema operativo qué son, html o hay alguna otra forma?

Cualquier cosa que se le pueda instalar ;). En iOS/Android cuento a Obj-C, Java (los dos nativos que ademas incluye C/C++), C#/Mono, Lua, Python, Delphi, HTML/JS, y seguro hay otros por ahi.

newtron

28-07-2014, 18:25:07

Al González

28-07-2014, 19:46:27

Cualquier cosa que se le pueda instalar ;). En iOS/Android cuento a Obj-C, Java (los dos nativos que ademas incluye C/C++), C#/Mono, Lua, Python, Delphi, HTML/JS, y seguro hay otros por ahi.
Se nota que has estado experimentando y aprendiendo mucho, Mario. Hace unos días encontré algo llamado "Smart Mobile Studio (http://smartmobilestudio.com/)". Entiendo que es Object Pascal "compilado" a JavaScript para correr en el navegador de cualquier dispositivo móvil. Pero, tú en lo personal, ¿qué opinión tienes de esta tecnología? ¿Qué ventajas y desventajas notas de Smart Mobile Studio sobre Delphi con FMX?

Extiendo estas mismas preguntas a los demás.

Un saludo. :)

mamcx

28-07-2014, 20:08:53

No no... creo que no me he explicado bien... me refiero a aplicaciones que se puedan usar sin descargar ni instalar nada.

Hasta el html requiere un browser instalado y que se actualize. Pero basicamente el mismo efecto se logra usando un autoupdater para apps nativas (una funcion que cumplen las appstore).

mamcx

28-07-2014, 20:14:34

Entiendo que es Object Pascal "compilado" a JavaScript para correr en el navegador de cualquier dispositivo móvil.

Osea, es un "transpiler (https://en.wikipedia.org/wiki/Source-to-source_compiler)". La ventaja es que corre en html, la desventaja es que genera javascript, que es particularmente un pésimo lenguaje (como target de un compilador, aparte de lo demás) y que es solo al titanico esfuerzo en los runtime de Google/Apple/Mozilla que se ha puesto manejable. Solo Mozilla esta intentando algo para hacerlo mejor (http://asmjs.org/)

Y ademas esto depende del soporte html en mobiles como un embebido, que no es muy optimo, no es nativo y carga todo el peso del navegador. Las app de phonegap y similares son muy poco fluidas y basicamente son para hacer apps nada pulidas pero "facil" para quienes manejan html/js.

En resumen: Si quieres hacer apps bien, html/js no es la opcion.

Al González

28-07-2014, 21:48:47

newtron

29-07-2014, 09:31:44

Gracias, Mario. Creo que entre más avanza este hilo, más deberes se le acumulan a newtron. :p

Pero ha de valer la pena: Cuando el caso quede resuelto, podría servirle de ejemplo a miles de creadores de aplicaciones Delphi que seguramente están en una situación similar.

Pues no sé si esto se me quedará resuelto porque si no he entendido mal las opciones son las siguientes:

1-Terminal server: casi descartado por el problema con las impresoras.

2-Citrix: no lo he estudiado a fondo pero dicen por aquí que es caro

3-Programa de escritorio con base de datos en "la nube": bueno, es una opción aunque no acaba de convencerme por tener que descargar la aplicación en modo local y mantenerla actualizada y habría que hacer una aplicación para cada windows/android/ios...

4-Programa html: es la que más me atrae por la facilidad de poder ejecutarse en cualquier dispositivo que disponga de un navegador aun con los inconvenientes de que no es la mejor opción para desarrollar y por otro lado habría que desarrollarla desde cero.

O sea, todas malas opciones. :confused:

Neftali [Germán.Estévez]

29-07-2014, 10:37:09

Échale un vistazo a los productos (comerciales) que hay en esta web (http://www.cybelesoft.com/).

Alguna vez hemos hablado de alguno de ellos (en concreto de WebFMX (http://www.cybelesoft.com/webfmx/) -Livedemo (https://webfmx.thinrdp.net/)-).
No son soluciones óptimas, pero tal vez sirvan como adaptación a aplicaciones ya hechas, que es lo que se está buscando.

newtron

29-07-2014, 11:47:05

pacopenin

31-07-2014, 17:42:23

Hola a todos.

Estoy haciendo pruebas de lo siguiente : Programa en Delphi (o Lazarus) y base de datos en internet. La parte de la nube la hago el php (aunque podría ser en cualquier otro lenguaje): desde el programa envío los datos mediante REST, recibo los datos como JSON y los cargo en datasets en memoria para el manejo local. Para lo que yo hago va muy bien: tienes toda la potencia y la facilidad del uso local de delphi y la base de datos en la nube. La velocidad es como la de cualquier aplicación web con la usabilidad de una aplicación de escritorio, y puedo seguir usando todos los componentes, código, etc que ya tengo. En local tengo dos ejecutables: un lanzador, encargado de comprobar si está actualizado el programa o no y el programa en cuestión.
Esto me da en principio muchas posibilidades: La parte de datos está hecha, con lo que puedo ir haciendo la parte de presentación de lo que que considere más necesario en html5 (responsive) para la accesibilidad desde cualquier dispositivo.
Esta idea me vino de trabajar con aplicaciones que tienen un programa cliente ejecutable como Evernote o el mismo Spotify y a la vez tienen programas web que hacen más o menos lo mismo. Con poco esfuerzo adicional tienes casi todo. Mis aplicaciones son sencillas y el volumen de datos, salvo alguna puntual excepción no es demasiado alto, así que de momento creo que servirá.

De momento tengo hechas unas cosillas para uso administrativo personal y otra a medida para un cliente con un cierto volumen de datos y está contento. Tarda menos de 2 seg en cargar, generar el dataset y mostrar un grid con todo para 2493 registros.

Todas las opciones de hacer algo parecido que conozco pasan por poder acceder al lado del servidor para montar cgi, etc. y ésto me permite trabajar con cualquier hosting.
Desgraciadamente nunca tendré 50.000 usuarios, así que....

Neftali [Germán.Estévez]

31-07-2014, 18:28:06

La parte de la nube la hago el php (aunque podría ser en cualquier otro lenguaje)

Personalmente me interesa si puedes desarrollar un poco más esta parte.
No hace mucho hice una pequeña incursión en PHP (muy muy pequeña) para una entrada relacionado con aplicaciones móviles; Para ello desarrollé algo en PHP (está explicado en esta entrada y en las relacionadas con detalle (http://neftali.clubdelphi.com/?p=3311))

¿Van por ahí los tiros?
¿Es algo similar lo que has desarrollado tú?
¿No puedes enviar algún ejemplo sencillo?

pacopenin

31-07-2014, 18:59:13

Neftali, lo mío es aún más sencillo, ya que prescinde de todo lo referente al webservice. La generación del JSON no es exactamente la misma que yo utilizo pero es parecida.

echo json_encode(array('Usuarios' =v arrusers));

Esta instrucción ya devuelve el JSON que necesitamos. Si llamas al php desde Delphi con la instrucción HttpPostURL(URL, Params, Response) de synapse (yo no utilizo INDY), el último parámetro es un Stream que recibe el JSON.

pacopenin

31-07-2014, 20:21:16

Realmente no hay demasiado que explicar. Un pequeño ejemplo :

$mysql = new mysql;
$mysql->server = $servidor;
$mysql->user = $usuario_base;
$mysql->pass = $password_base;
$mysql->connect();
$mysql->select($bd);

$sql= "SELECT * FROM CLIENTES";

$query = $mysql->query($sql);

$rows = array();
while($r = mysql_fetch_assoc($query)) {
$rows[] = $r;
}
print json_encode($rows);

Response := TMemoryStream.Create;
try
TCli.EmptyTable;

URL := 'http://localhost/test_json/test_json.php';
Params := '';

{ Params := Params + '&nombre=' + EncodeURLElement('Francisco Penín');
Params := Params + '&app=' + EncodeURLElement('1');
Params := Params + '&id=' + EncodeURLElement('52b350356d63e');}

if HttpPostURL(URL, Params, Response) then
begin
P:=TJSONParser.Create(StreamToString(Response));
try
P.Strict:=True;
D:=P.Parse;
TCli.disableControls;
for i:=0 To D.Count-1 do
begin
T := D.Items[i];
TCli.append;
TCliID.asInteger := T.Items[0].AsInteger;
TCliNombre.asString := QuitaComillas(T.Items[3].AsJSON);
TCliDomicilio.asString := QuitaComillas(T.Items[9].AsJSON);
TCliPoblacion.asString := QuitaComillas(T.Items[8].AsJSON);
TCliTelefono.asString := QuitaComillas(T.Items[12].AsJSON);
TCli.post;
end;
finally
P.Free;
TCli.enableControls;
end;
end;

finally
Response.Free;
end;

mamcx

01-08-2014, 03:30:44

En python, http://bottlepy.org/docs/dev/index.html es lo mas simple para hacer esto. Es trivial hacer REST (http://gotofritz.net/blog/weekly-challenge/restful-python-api-bottle/).

Neftali [Germán.Estévez]

01-08-2014, 09:12:48

Realmente no hay demasiado que explicar. Un pequeño ejemplo :

Muchas gracias por la muestra.
^\||/

newtron

01-08-2014, 10:07:27

desde el programa envío los datos mediante REST, recibo los datos como JSON y los cargo en datasets en memoria para el manejo local

Además de tener pocos registros imagino que será una aplicación que solo hará consultas, ¿no? porque en caso de tener que grabar datos ya el tema se complicaría si usas tablas locales en memoria.

pacopenin

01-08-2014, 10:52:32

Además de tener pocos registros imagino que será una aplicación que solo hará consultas, ¿no? porque en caso de tener que grabar datos ya el tema se complicaría si usas tablas locales en memoria.

En el ejemplo que puse se puede ver como definir parámetros que se pueden pasar a PHP

Params := '';

{ Params := Params + '&nombre=' + EncodeURLElement('Francisco Penín');
Params := Params + '&app=' + EncodeURLElement('1');
Params := Params + '&id=' + EncodeURLElement('52b350356d63e');}

if HttpPostURL(URL, Params, Response) then

Desde PHP se pueden recibir parámetros http://php.net/manual/es/language.variables.external.php es decir, según el ejemplo anterior

$nombre = $_GET['nombre];

aquí se puede hacer el insert, update, delete o lo que queramos.

En definitiva el funcionamiento es similar a las aplicaciones web. HTML llama a PHP pasando valores. PHP hace operaciones con la base de datos y devuelve resultados. HTML recibe los resultados y los presenta. Cambiamos HTML por Delphi.

Y lo del volumen de datos es relativo, si haces consultas que devuelvan muchos miles de registros toca esperar. Para mi no tiene mucho sentido que si tienes 100.000 registros en una tabla los cargues todos y luego apliques filtros, busquedas, etc sobre memoria. El ejemplo que puse más arriba carga 2.500 registros en menos de 2 segundos, así que en la mayoría de los casos es más que suficiente. No se me ocurren demasiados casos en los que se necesiten tener cargados tantos registros a la vez. Pero vamos, eso va con la forma de trabajar de cada uno.

pacopenin

01-08-2014, 12:25:27

Personalmente me interesa si puedes desarrollar un poco más esta parte.
No hace mucho hice una pequeña incursión en PHP (muy muy pequeña) para una entrada relacionado con aplicaciones móviles; Para ello desarrollé algo en PHP (está explicado en esta entrada y en las relacionadas con detalle (http://neftali.clubdelphi.com/?p=3311))

Estuve echándole un vistazo al post completo que pusiste ya que ayer sólo había mirado la página 2 que habías enlazado, y veo que en la página 3 tienes exactamente lo mismo que yo comento, pero además muy bien explicado y con mejor código que el mío.

roman

04-08-2014, 18:14:21

Neftali [Germán.Estévez]

04-08-2014, 18:42:57

¿En qué sentido lo que comentan en los últimos mensajes es una aplicación en la nube?

Pero es que a mi me parece una aplicación de escritorio con una base de datos en internet y con una especie de intermediación de php, que no me queda claro para qué es o qué diferencia hay entre hacer directamente la consulta desde delphi.

¿O es que toda aplicación que use una base de datos en internet se considera un aplicación en la nube?

Tienes razón Román, eso no es más que una aplicación Delphi con la Base de Datos en Internet, pero tal y como ha dicho pacopenin (http://www.clubdelphi.com/foros/showpost.php?p=479562&postcount=48)(y creo que por ahí ha salido esta opción) es una situación "intermedia" que te da acceso a otras posibilidades.

Esto me da en principio muchas posibilidades: La parte de datos está hecha, con lo que puedo ir haciendo la parte de presentación de lo que que considere más necesario en html5 (responsive) para la accesibilidad desde cualquier dispositivo.

La idea, al menos lo que a mi me ronda, es que de una aplicación ya existente (desktop), con "poco" (o no tan poco...) podemos pasarla a este escenario. Y desde este escenario, podemos mantener la Base de Datos y la aplicación de escritorio y en paralelo ir desarrollando otras aplicaciones que funcionan en ese mismo ecosistema. Sea una página web, sea una aplicación web, sea un desarrollo móvil,...

Así que, no es que esa solución sea "una aplicación en la nube", pero parace un paso intermedio "asequible" entre:
Aplicación desktop Delphi actual <==> Desarrollo en la nube
(que al final era de lo que trataba la pregunta)

Al menos a mi me ha interesado por esta visión.

newtron

04-08-2014, 18:59:41

Pues después de todo este rollo yo pienso que un "programa en la nube" tiene que ir en un browser para poder ejecutarlo desde cualquier dispositivo y sin instalar ningún programa local, lo que decía unos cuantos mensajes atrás... que entres en una web que te pregunte tu usuario y contraseña y accedas a tu programa.

Neftali, los componentes que me comentas tienen buena pinta y darían ese resultado porque en teoría convierten tu programa de escritorio en un programa html pero yo no veo muy claro el tema del alojamiento de la base de datos, llamadas a la api y cosas así.

roman

04-08-2014, 19:17:48

Pues después de todo este rollo yo pienso que un "programa en la nube" tiene que ir en un browser para poder ejecutarlo desde cualquier dispositivo y sin instalar ningún programa local, lo que decía unos cuantos mensajes atrás... que entres en una web que te pregunte tu usuario y contraseña y accedas a tu programa.

Pues sí. Creo que es el concepto en sí lo que es confuso. Para mi, desde mi ignorancia, un programa en la nube es algo tipo Office361 o Google Drive. O bien, puedo considerar un servico como DropBox como parte de la nube pues me permite tener archivos disponibles desde cualquier parte; pero una base de datos no la consideraría parte de la nube, pues al menos en mi caso, siempre han estado ahí.

// Saludos

nlsgarcia

04-08-2014, 19:37:24

roman,

...¿O es que toda aplicación que use una base de datos en internet se considera un aplicación en la nube?...

:rolleyes:

Básicamente un programa que sea del tipo Cloud Computing debe correr sobre una plataforma para tal fín (Amazon EC2 (http://aws.amazon.com/ec2/), Windows Azure (https://azure.microsoft.com/en-us/), Google Cloud Platform (https://cloud.google.com/), IBM Cloud (http://www.ibm.com/cloud-computing/es/es/)), sobre una máquina virtual (Servidor) como un servicio (SaaS (http://en.wikipedia.org/wiki/Software_as_a_service)).

Si el programa esta instalado sobre un dispositivo móvil o fijo y accede a uno de los servicios de Cloud Computing, por ejemplo una base de datos (PaaS (http://en.wikipedia.org/wiki/PaaS)), entonces el programa no es del tipo Cloud Computing pero utiliza recursos de esta plataforma en un modo híbrido. Un ejemplo que ilustra la idea anterior es el desarrollo de un programa en Delphi que acceda a una BD en un AS/400, definitivamente el programa en Delphi no puede ser considerado un programa del AS/400 (No es ejecutado en el entorno del OS/400), pero ciertamente utiliza el DB2/400 como fuente de datos :rolleyes:

Revisa esta información:

Which programming language for cloud computing? (http://stackoverflow.com/questions/3740692/which-programming-language-for-cloud-computing)
Espero sea útil :)

Nelson.

pacopenin

04-08-2014, 19:46:20

Hola,

¿En qué sentido lo que comentan en los últimos mensajes es una aplicación en la nube? No es crítica, es ignorancia mía. Pero es que a mi me parece una aplicación de escritorio con una base de datos en internet y con una especie de intermediación de php, que no me queda claro para qué es o qué diferencia hay entre hacer directamente la consulta desde delphi. ¿O es que toda aplicación que use una base de datos en internet se considera un aplicación en la nube?

// Saludos

Para mi, el punto de partida para que una aplicación pueda ser considerada en la nube, es que los datos estén en internet, bien sean bases de datos, archivos, correo, etc. A partir de ahí debemos articular el acceso a esa información de forma limpia y fácil para el usuario. Lo normal es hacerlo en algún mediante una aplicación web que universaliza el acceso a dicha información.

Está muy bien expresado lo que comenta Netfali, y mi idea va por ahí. A mi me está abriendo muchas posibilidades: poder entrar de lleno en el alquiler de programas y pago por uso, simplificar al máximo las instalaciones locales ya que no hay base de datos local, simplifica al máximo el mantenimiento de versiones de cada programa, acceder desde cualquier lado. Otra posibilidad es simplificar y economizar en empresas de ubicaciones distribuidas, tiendas, etc. puedes eliminar terminal server p.e.: basta poner un Apache en su servidor y direccionar puertos, etc. Todo esto son ventajas que para mi son importantes.

En cuanto a tecnología, el concepto no varía de lo que es una aplicación web como ya dije antes :
Un aplicación web tiene dos partes : cliente (HTML, CSS, Javascript) y servidor (PHP, Python, etc).
La parte del servidor es exactamente igual si es una aplicación web o lo que yo comento : el PHP recibe peticiones y parametros. Procesa la información, actualiza y/o consulta la base de datos y devuelve texto (si texto puro y duro). Ese resultado hay que presentarlo, y se puede hacer en un navegador, mezclando HTML, CSS y Javascript (este último si hay que interactuar). Lo que yo hago es que ese resultado lo presento en delphi. La parte de PHP sería la misma si se pasan los mismos parámetros, es decir para insertar un registro desde un formulario web se diseña un form con submit que llama a PHP pasando los campos del formulario como parámetros. Pues desde delphi pasas los mismo parámetros y funcionaría exactamente igual.

Hay varios inconvenientes, el principal es que no es un cliente universal, pero con las opciones multiplataforma de Delphi o Lazarus y trabajando en local con texto, sin la necesidad de tecnología de acceso a datos, ni base de datos instalada todo se simplifica bastante. Cara a dispositivos móviles iré haciendo alguna cosilla web sobre todo para consultas y a partir de ahí ya iremos viendo.
Como ya comenté para mi es válido a día de hoy sin tener que empezar de cero en tecnología ni recursos (el hecho de tener que rehacer ni un solo informe ya vale un mundo).