Infosytech Solutions Inc

Home » Technology

Enterprise Application Integration (EAI) Practice:

Infosytech's EAI Practice is concentrated in the TIBCO Suite of Products.

Businesses need real time information to make optimal business decisions. This desire for accurate and timely information is often hindered by stand-alone applications and the heavy expense of acquiring an enterprise system. Infosytech provides a technology solution to these ongoing business concerns by allowing companies to continue to reap the benefits of their present IT investments and yet acquire enhanced distribution and availability of data.

At Infosytech Solutions Inc - Enterprise Application Integration ( EAI ) services provides Web-based application services which support multiple platforms, integrates existing applications, and permits sharing of information within a company and with suppliers and customers. Consequently, this integration of applications allows a company to operate as an enterprise entity.

From initiation through development, testing, implementation and training to monitoring and maintenance, Infosytech consultants work in collaboration with your IT professionals and end users. The result is a cost-effective, state-of-the-art information system.

We have a Superdome TIBCO practice equipped with TIBCO Certified Professionals that provide our clientele with the Development, Administration and Support.

TIBCO Business Works

TIBCO Business Events

TIBCO Business Connect

TIBCO ActiveMatrix

TIBCO Hawk

Different ESB vendors came up with their own flavors of SOA integration suites which commonly included a Messaging layer and an Integration Designer.

ESB "Suite"= ESB Messaging Layer + Data Models + Integration Platform (Ex: TIBCO Business Works / BEA Aqua logic etc.)

ESB = Messaging Layer ( Ex: Java JMS, Tibco RV etc.) + Data Models (Proprietary or/and Common Schemas)

"ESB is a logical infrastructure realized using the messaging channels and the data that flow through it. The data flowing through the messaging channel can be either proprietary to the end point systems that are involved in the communication or it could be common data across a number of agreeing systems."

ESB should not realize/implement any additional business logic in a perfect Service Oriented Implementation. Implementation of Business Logic must happen through Integration designer of the ESB suite in the inbound and outbound transformations. In a way, ESB must be loosely coupled.

In summation, there must be a proper/clear separation (handoff) between the transformation part of ESB suite and the Data models in ESB. This handoff must be done using the Messaging portion of the ESB (For Ex: Queues and Topics, if JMS is used as the Messaging layer). It is the integration platform in the ESB Suite that should deal (exclusively and limited to) with the transformation and validation of the business logic.

EAI Practice - Webservices and SOA :

Webservices have become the part and parcel of every mordern SOA implementation.

Demystifying the contemporary jargon of Webservices with the vast expertise around this field, we would explain here ‘our’ school of thought which is based on the experience creating and deploying hundred's of webservices for disparate business needs with various styles, usages and transports.

Questions that should come to one's mind when designing a Webservice:

SOAP Vs REST

Binding Vs Use

Document Vs RPC

Literal Vs Encoded

HTTP Vs JMS transports (Lets consider HTTP and JMS to be two common industry transports in our discussion here)

Service Requester and Service Provider mediation in a WebService

Webservice:

A webservice is defined as a peice of code that when bound to a protocol, the message in it travels on a transport (Http or JMS etc.) from a Service Provider to a Service Requestor and vice versa. The binding can be either a Document or RPC with USE being a Encoded or Literal. So what is Binding in webservices ?

SOAP and REST Webservices:

Though the concept of REST (Representational State Transfer) has been out there for a while, REST based webservice is relatively a new concept when compared to the SOAP webservice. REST webservice came to prominence in early 2003-2004 where as SOAP specification dates back to early 1998. Yahoo and Amazon have been the biggest supporters of REST services where as Google uses the SOAP based webservices for the most part. We will have a detailed discussion of SOAP Vs REST in another blogpost.

Webservice Binding : Document Vs RPC:

Document and RPC are two communication styles that translates a WSDL and links(binds) to a SOAP message body that either uses a literal or encoded version of use model.

The advantage with the Document style is that one could structure the SOAP body the way they want i.e the content can conform to any arbitrary XML structure. With RPC binding style, a SOAP body must contain both operation name and set of method parameters.

Webservice Use : Literal Vs Encoded:

With ‘literal’ encoding, this SOAP message could be validated against any XSLT transform or XSD transformation since the SOAP body conforms to an existing schema structure.

‘Encoded’ usage isn't much preferred in real world applications since a SOAP message is not easy to validate as the SOAP body structure need not follow any XML based structure though it has the XSD types defined at the field level.

SOAP over HTTP Vs SOAP over JMS:

The usage of SOAP over HTTP transport versus the SOAP over JMS transport comes from a necessity than an organization style unlike most folks really think about. If the Business requires a synchronous real-real time interface, then Http transport is used, but this flexibility comes with a inherent drawback of loosing transactions incase of network failures.

In a situation where the Network outages are not avoidable, I would recommend a asynchronous mechanism of transport (for Ex: JMS queuing). Also, take in to the performance and SLA before choosing one transport over the other.

We have our employees working in various TIBCO implementation clients.