Taller Desarrollo de apps para android/iphone/ipad (phonegap)

Phonegap es una plataforma de código abierto, que posibilita a los desarrolladores a que implementen sus proyectos utilizando las tecnologías estándar de web: HTML5, CSS3 y Javascript, permitiendonos empaquetar y generar aplicaciones “nativas” (ejecutandose en el navegador nativo de las terminales – webkit).

El objetivo principal es que lo participantes conozcan las nuevas tecnologias relacionadas con el desarrollo de aplicaciones moviles mas populares para los dispositivos mas utilizados en la actualidad (terminales android, iphone, ipad, blackberry, y especificamente con el framework Phonegap, y poder servir como primer acercamiento a la tecnologia, motivandolos a adentrarse mas a phonegap para realizar aplicaciones para dispositivos moviles (smartphone, tablets).

Taller Desarrollo de apps para android/iphone/ipad (phonegap), inicio Lunes 16 de Enero del 2012

Mas detalles en

Hack HTML5 in IE6-7

For those who are doing web development in HTML5, and we have the unwelcome surprise that IE does not work in our application (Microsoft and fragmentation blessed with their versions of browsers), we can apply a very simple hack, which can be 2 ways:

1. On a piece of javascript in the HTML
2. In a separate javascript file

document.createElement(“article”);
document.createElement(“footer”);
document.createElement(“header”);
document.createElement(“hgroup”);
document.createElement(“nav”);

and ready, IE will render correctly (at least those elements HTML5).

 

Tekne Intellegentia Web Site released

Tekne Intellegentia Web Site has been released, soon we will be adding more content about our services and upcoming products

Application Server

>Plataformita HL7

>Has been concluded with the development of the Platform Test Controlled Electronic Health Record (with HL7 messaging) of the Ministry of Health of Mexico (Alias Plataformita) by consultants Tekne Intellegentia (http://www.tekneintellegentia.com .) Soon we will address a more detail on the implementation

>SOA, EIA, ESB Blah Blah Blah, How to select the appropriate?

>

Here are some important points left to be considered for any ESB able to choose to go to this principle, which is an ESB?

An ESB is the implementation backbone for a loosely coupled, event-driven SOA that enables a highly distributed universe of named routing destinations across a multi-protocol message bus.

An SOA provides an integration architect with a broad abstract view of applications and integration components to be dealt with as high-level services. Service components in an ESB expose coarse-grained, message-driven interfaces for the purpose of sharing data between applications, both synchronously and asynchronously. In an ESB, applications and event-driven services are connected through the bus as abstract endpoints. These abstract endpoints are tied together in a loosely coupled SOA, which allows them to operate independently from one another. An integration architect uses an ESB to tie together assemblies of abstract endpoints that form composite business processes, or process flows.

What the endpoints actually represent can be very diverse. For example, an endpoint may represent a discrete operation, like a specialized service for calculating sales tax. The underlying implementation of the endpoint could represent a local binding to an application adaptor, or a callout to an external Web service. The applications and services can be physically located anywhere that is accessible by the bus.

Requirements to scale business an ESB

Messaging distributed: The core of what constitutes an ESB implementation of middleware-oriented message. This core provides a reliable method of transport and distributed to employs a mechanism for storing and forwarding through which ensures delivery of messages even if anomalies in the network.

Transparency of locations: With the mediation between services, a service customer invoking the service provider only needs to know that the service there, the customer does not need to know where is running the service. The ESB locates the service when it is invoked. This provides a certain level of virtualization of services and transparency of the locations, so that if a team fails, or if you change the location of a service provider, it is not necessary notifies the change to each individual customers. This may contribute significantly reducing management costs and minimize IT Risks.

Transparency transport: In traditional approaches to integration point to all components and objects are very closely connected. In the SOA, services are scattered throughout the IT environment and its coupling is less strict, thanks to the transparency of locations. Apart from relying in the transparency of locations for connecting customers and suppliers services, the ESB also provides physical transport protocol to possible communication between services using different transport.

Support Multi Protocol: Because it raises questions of reliability inherent and only works well with patterns of exchange of messages (MEP) synchronous, the HTTP transport model does not meet the requirements of all services and applications. For example, Java Message Service (JMS) plus to possess characteristics asynchronous, offers more reliability in the transportation

HTTP. To reconcile the behavior of individual applications, some systems rely on SOAP across MO. He also used other type’s models of transportation, including transportation systems Owners of some of the leading suppliers of systems and solutions ERP. ESB needs, hence, be able to endure many types of transportation systems to integrate disparate systems and manage complex transportation communications effectively.

Quality of service: In enterprise applications, the quality of service (QOS) refers mainly to their reliability. The delivery of messages and reliability of services invocation are mission-critical functions of any system. Even Web services alone does not offer a service Delivery guaranteed. An ESB, on the other hand, can provide a service high reliability ensuring delivery of the message from start to finish that goes far Apart from the reliability that can provide transportation as MO. Also, methods used to achieve a high level of QOS must meet Existing standards, for example, be compatible with the specification WS-ReliableMessaging.

Patterns of exchanging messages: At present, most of the ESB are based on a paradigm request / response using SOAP over HTTP, and this means that the customer service launches a message to the user request and hopes to get the answer. This is known as an MEP synchronous. However, the MEP of publication / subscription service customer can send a message and subscribe to the response, rather than wait to receive it. The MEP of publication / subscription can respond more effectively to events in a business context, particularly when the life cycle of an action service takes place during extended periods of time. An ESB must be able to handle both paradigms.

Content Based Router: There are two types of routing within an ESB. The first service routing occurs when invoking a service falls within the ESB and he headed the response to service provider Appropriate, without the need for customer service knows the location of service provider. That’s how it achieves transparency in the locations before we commented. The other content-based routing, introduces a series of rules or a business logic that applies to the content of the message in the stage of routing and allow the ESB route messages to suppliers service based on their specific content; prioritizing, for example, orders for certain customers or checking orders for large give them special treatment. This gives companies a valuable service, and that can help reduce the cost of information management, ensures that compliance with the existing level of service and allows companies to focus on activities to improve customer satisfaction.

Transformation: While the task of an ESB is to direct messages to a service next, there are occasions when the data format of a service does not meet the requirements of the next service. For that reason, the ESB must be able to transform data from one format to another.

Additional criteria for evaluation

When deciding what would be the best tool for integrating a SOA, in addition to assessing the characteristics precedents should also pay particular attention to the following criteria:

Open standards: Open standards, SOAP, WSDL and JBI, are an integral part of the requirements of an enterprise SOA. Therefore, both components of the solution ESB (container time Implementing messaging infrastructure, services and integration of notations design time) as mechanisms for the integrated resources involved on the bus (attach request and respond) should be consistent with these open standards.

Scalability and high availability: To meet the needs of a business The ESB must be able to manage a large volume of messages. Also, it is essential that offers high availability to ensure the functioning uninterrupted business. If an element of the ESB failure should not assume that necessary for communication services. These criteria are helping IT departments to ensure that the ESB will be able to manage the burden of transactions necessary in a fast, reliable and sufficiently room for future growth, an essential element that ensures the agility of business.

>Benchmark ESB Open Source

>

I share with you a benchmark between ESB Open source, this information to enrich comments are welcome 

 

Features JBoss ESB Service Mix Mule Open ESB
Version 4.2.1.GA 3.2.1 (4 in Beta) 2.0 2.0 (3 in preview)
  • Service (as Actions)

  • Endpoint (as Listeners)

  • Transport (as Providers)

  • Routing

  • Transformers (as Actions)
  • JBI Components

  • Endpoints

  • Transports

  • Routing

  • Transformers

  • Models, Service & Components

  • Endpoints

  • Transports

  • Routing

  • Filters

  • Transformers
  • JBI Components

  • Endpoints

  • Transports

  • Routing

  • Transformers

Spring Enabled No Yes Yes No
Clustered

Yes:

  • With JMS

  • With JBoss Clustering

Yes:

  • Network of Service Mix containers (Static Network Connectors, multicast)

  • With JMS

Yes, 2 Types:

  • With Terracotta

  • With JMS

Yes:

  • Provides by Glassfish

  • With JBoss Clustering (configuration server JBoss)
Scripting

Yes,

Groovy

Yes,

Groovy

Yes,

Groovy

PHP

JavaScript

Yes,

JavaScript

Groovy

JRuby

Deployment Type
  • Standalone.

  • Server Mode (as JBoss AS – JbossESB Server)

  • Standalone (as Server)

  • In App Server with Deployer Module

  • Embeddable in Web Application (war).
  • Standalone (as Server)

  • in App Server with JCA Connector

  • Embeddable in Web Application (war).
  • With GlassFish (openESB runtime included)

  • In App Server (as new Configuration server in JBoss)
Transport Implementations Supported
  • JMS

  • JBossWS

  • File based

  • FTP

  • HTTP

  • Email

  • JDBC

  • Hibernate

  • Jboss Remoting

  • Groovy

  • Scheduler

  • JCA

  • SOAP

  • CFX/Xfire

  • Email

  • File based

  • FTP

  • HTTP

  • XMPP (jabber)

  • JMS

  • RSS

  • VFS

  • WSIF (with support to Axis, local Java, EJB, JMS, JCA and CCI).

  • Quartz

  • Axis WS

  • CXF WS

  • SOAP WS

  • EJB

  • Mail (pop/imap/smtp)

  • RMI

  • HTTP(s)

  • Servlets

  • JDBC

  • JMS

  • File

  • FTP

  • Jetty

  • JNP

  • VM

  • SSL,TLS

  • STDIO

  • Multicast

  • TCP,UDP

  • Quartz

  • XMPP (jabber)

  • File

  • FTP

  • HTTP

  • JMS

  • JDBC

  • Email

  • XMPP(jabber)

Transformation
  • Smooks (support to XML to XML, CSV to XML, EDI to XML, XML to EDI, XML to CSV, Java to XML, Java to EDI, Java to CSV, Java to Java, XML to Java, EDI to Java)

  • Xslt

  • Binary Transformation (ObjectToXStream, ObjectToCSVString)
  • Xslt

  • Drools rules

  • Pojo Beans

  • Scripting Groovy

  • Custom transformation (by developer).

 

 

 

  • JMSMessageToObject & vise versa

  • Pojo Beans

  • Stream to Object & vice versa

  • Xml to Bean & vice versa

  • Encrypted String to String

  • String to Email Message

  • Xstl Transformation to HTML

  • Dom to Xml & vice versa

  • Scripting with groovy

  • Jxpath

  • GZipCompressTransformer GZipUncompressTransformer

  • Encoder to Decoder & vice versa

  • ByteArrayToSerializable & vice versa

  • StringToByteArray & vice versa

  • Custom transformation (by developer).
  • Xslt

  • ETL Data(Extract,Transform,Load)
Routing
  • Content Based Routing.

  • WireTap.

  • Message-Filter.

  • Aggregator

  • StaticRouter
  • Implemented with EIP

  • Content-Based Router

  • Message Filter

  • Pipeline

  • Static Recipient List

  • Static Routing Slip

  • Wire Tap

  • XPath Splitter

  • Aggregator

  • Content Enricher

  • Resequencer
  • Aggregator

  • Resequencer

  • Idempotent Receiver

  • Selective Consumer

  • Selective Consumer

  • WireTap Router

  • Recipient List

  • Multicasting Router

  • Chaining Router

  • Message Splitter

  • Exception Based Router

  • Filtering Message Splitter (List & Xml)

  • Others (Response aggregator, Filters, Nested Router,ReplyTo)
  • Implement IEP Routing, no more details.
Security
  • JAAS

  • Spring Security

  • JAAS

  • PGP
  • Spring Security

  • JAAS

  • PGP
  • Glassfish Realm Security

  • Access Manager
Tools
  • jBPM Console

  • Monitoring and Management Console

  • Alerts Web Console (JBossAS within JBossESB).
  • Archetypes in Maven for RAD

  • Service Mix plug-in to Deployment Task with maven.

  • CIMERO Eclipse Plug-in for Developer (Only Service Mix 3.0)

  • Web Console Administration

  • Ants tasks (Administrative)

  • Mule IDE (Eclipse Plug-in).

  • Archetypes in Maven for RAD (Project, Modules, Transport)

  • JBI Manager, available with the NetBeans IDE

  • ANT Task Reference and ANT Target Reference

Task for Developer
  • Actions for Transform, Route, Business.

  • Xml Configuration to bus

  • Deployment Package (in esb file)
  • Customer Transport (as Binding Component)

  • Customer Component (as Service Engine)

  • Customer Transformers (as Service Engine)

  • Xml Configuration to Bus (xbean.xml)

  • Deployment Service Assembly
  • Component Service as POJO / Scripting

  • Custom Transformers

  • Custom Transports

  • Custom Mule Events & Agents.

  • Xml Configuration to Bus

  • Deployment Component (in a jar file).
  • Customer Transport (as Binding Component)

  • Customer Component (as Service Engine)

  • Customer Transformers (as Service Engine)

  • Xml Configuration

  • Deployment Service Assembly
Configuration Flow In Xml File with Jboss ESB Schema. In Xml Files with Xml Spring type, used schemas to implement xml configuration (xbean.xml, jbi.xml)

In Xml Files, 2 types

Mule Type

Spring Type

 

Used schemas to implement xml configuration

In Xml wsdl files, orchestration in BPEL, jbi.xml.
Component Implementation. Simple POJO as “Actions” JBI (Binding Component, Service Engine – Service Unit –Service Assembly) Simple POJO as Component JBI (Binding Component, Service Engine – Service Unit –Service Assembly)
Additional Configuration Files

Yes:

  • To Service Registry (uddi)

  • To Message Store

  • Others (JMS Queues, log4j, etc)

Yes:

  • JBI Service Assembly

  • To Security, to engine service mix, to components, to ActiveMQ embedded, jmx, jndi.

No

Yes,

  • JBI Service Assembly

Others
  • JBPM

  • Service Registry (uddi)

  • Message Store (Store all events in bus).

  • Drools Rules (used in Routing)

  • BPEL

  • JMX

  • Added Spring as External

  • Event Notification
  • JBPM

  • JNDI

  • Drools Rules

  • JMX

  • Bean Flow (a Workflow managed by beans)

  • Threads Pools by Component (Configurable)

  • Client API

  • Transaction (synchronous & asynchronous, defined in flow)

  • Validation vs. Schemas

  • BPEL
  • JBPM

  • REST

  • JNDI

  • Quartz

  • Transaction with jomt & mule providers (vm, jdbc, jms). Simple & XA

  • JMX

  • Client API

  • Pluggable with JBI Components of others ESB

  • Integration with JavaSpaces Implementation ( as GigaSpaces)

  • Server Notifications (Custom implementation)

  • Mule Agents (Not managed components)

  • Internationalization

  • Exception Strategies

  • WorklListManager

  • SQL Service Engine

  • JMX

  • Events Processor

  • SIP Binding Component

  • SNMP Binding Component

  • DCOM

  • CORBA

  • BPEL

  • Third part components.
Advantages
  • Easy Configuration

  • Use resource of JBoss (included in AS).
  • Based in JBI Components Standard

  • Complete API

  • Spring Integration
  • Easy Configuration & Implementation

  • Spring Integration
  • Full support in netbeans IDE to Developers (graphic BPEL modeling).

  • Based in JBI Components Standard

Disadvantages
  • High learning-curve for JBI

  • Draft still immature in comparison with other technologies

  • This initiative (JBI few components themselves)

  • Not its container for JBI
  • high learning-curve for JBI

  • Complex Xml Configuration (Schema Service mix to Endpoints & Components).

  • High knowledge in Maven to use the tools RAD

  • XML-based communication, good for integration but overloading the network bad thing
  • Not its container for JBI Components.

  • In IDE to developers, all schemas not currently supported..
  • Low Documentation

  • high learning-curve for JBI

  • High knowledge in WSDL & WS-BPEL.

  • XML-based communication, good for integration but overloading the network bad thing
Books
  • Only books of SOA, Enterprise Integration Patterns.

  • Only books of SOA, Enterprise Integration Patterns.

  • Open-Source ESBs in Action, Example Implementations in Mule and ServiceMix by Manning
  • Mule 2: Official Developer’s Guide to ESB and Integration Platform (Firstpress) by Peter Delia and Antoine Borg (Paperback – Aug 1, 2008)

 

  • Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (The Addison-Wesley Signature Series) by Gregor Hohpe and Bobby Woolf

  • Open-Source ESBs in Action, Example Implementations in Mule and ServiceMix by Manning
  • Only books of SOA, Enterprise Integration Patterns.

Support

Yes;

  • Subscription (24×7 or 9am-9pm)

  • Training (jBPM, Rules, ESB)

  • Consultant Service.

  • Documentation online (in community, Wiki, Forum, Mailing List/FAQ)

Yes,

  • Issue Tracker

  • Discussion Forums

  • Mailing Lists

  • FAQ

  • Consulting Service

  • Educational Service (Custom/Public)

  • Support (Production 24×7,Developer 8×5, Number of Incidents Unlimited)

Yes,

  • 24×7 or hourly support (Number of Incidents 10 to Unlimited)open ESB support

 

  • Mailing list/user list/Jira issue tracker, FAQ

  • Consulting Service

  • Educational Service

  • Documentation online

  • Events

Yes,

  • Consulting/training Services by Partner

  • Documentation online (low), Wiki, User docs, FAQ, Blogs, Mailing List, forums).