<<Establishing communication between disparate technology platforms is one of the holy grails in enterprise computing, ever so with the focus by most IT departments on avoiding information 'islands' within an organization. In fact, the appeal to service-orientated architectures (SOA) is to avoid such 'islands' by a having most resources available as a service. Next, I will describe a project named Thrift and how it tackles a unique problem set in SOA.
In order to better understand the problem Thrift addresses, its necessary to take a step back into more popular SOA approaches. Services designed around REST and SOAP principles are among the most popular in today's web bound applications, using such an approach platform disparities are shielded by the use of XML payloads and WSDL/WADL descriptors, with any technology platform or programming language being 'wrapped' around said approach to bridge disparities. Prior the to appearance of REST and SOAP, distributed communication was achieved -- and is still often resolved -- by means of technologies like DCOM and CORBA. In principle these last technologies just like REST and SOAP also attempt to shield underlying platform disparities by 'wrapping' end points in a common approach. All these distributed communication technologies while a big step toward avoiding information 'islands', also bring overhead and complexity when applied to a growing body of intra-company applications. This has given way to another breed of environment aimed at coordinating the parties involved in distributed communication. Products based on the Java Business Interface(JBI) standard or Microsoft's own BizTalk server are aimed at coordinating different client and server applications, fulfilling a business process irrespective of the underlying technology platform used by either client or server. These last products though, cover many integration scenarios ranging from enterprise messaging to more sophisticated support like the use of BPEL (Business Process Execution Language). In addition, they are often overly complex and ironically enough due to their own standardized approach. As it turns out, the support for a new distributed technology into the integration process can increase complexity exponentially, due to peripheral cases that may be standard in one platform but nonexistent in another. Such discrepancies are the achilles heel behind core distributed technologies like CORBA, where for example, creating a client in a programming language like C++ or C to communicate with a server in Python or Java can become complex; are data types in both languages represented equally? How are errors interpreted between each language? Issues like these are peripheral cases that need to be taken into account, and the longer the list of supported programming languages the more elaborate an exchange between client and server can become. So lets say you had a wish-list to support as many programming languages as possible, with absolutely no interest in peripheral cases in order to increase simplicity, strictly deal with services, and still wanted some of the main features available in an integration environment like JBI or BizTalk, enter Thrift . Thrift is an open-source project under the guidance of the Apache software foundation, which eases cross-language services development in the following programming languages: C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml. What Thrift eases is the creation of clients and servers, whilst providing and managing all the 'plumbing' necessary for distributed communication, where 'plumbing' can be understood as communications links, protocols, object serialization and socket management, among other things. In essence, Thrift allows developers to concentrate on the business logic of a service, using any of the twelve supported languages. If a service's logic requires heavy use of asynchronous algorithms it can be written in Erlang to ease development, or Java if a team's expertise is tilted toward this language or Ruby if a service needs to be integrated with a web application written in Ruby on Rails. The way Thrift achieves this flexibility is through Thrift files or contracts. A Thrift file or contract contains a service's data types and method signatures, similar in nature to other language neutral contracts used in SOAP and CORBA -- WSDL and IDL contracts, respectively. Once a Thrift contract is designed, it can be used to generate the necessary stub in any particular language needed to create either a client or service implementation of a service, and have a developer fill in the necessary business logic in whichever language is most suited for the task. A process similar in nature to SOAP and CORBA. However, Thrift stubs are clearly different from these other technologies, in the sense they contain protocol and socket methods (a.k.a.'plumbing code'). Thrift contemplates this since its specifically focused on services, and does so using its own protocol, client abstraction and server abstraction, not to mention relying on a very pragmatic approach for defining types that can easily be mapped between the twelve languages it supports. In this sense, Thrift's support for client and server abstraction makes it overlap with the features available in some integration products, where as its contract and code generation approach make it resemble distributed technologies like CORBA. Inclusively, in areas like versioning that can prove pivotal to enable staged roll-outs of changes to deployed services, Thrift is in a class of its own supporting service versions, especially when many programming languages used to back services lack or have contrived manners of dealing with run-time versioning. As to who uses Thrift, prior to its promotion as an Apache project it was under the guidance of the Facebook engineering team, which says a lot about its real world utility. With close to a 100 million users, its hard to imagine the requirements for this site's applications being fulfilled by a single programming language or platform. Thrift has been a big part of letting individual groups choose a programming language based on team and domain strength, and relying on Thrift for the integration of services available in their internal cloud. So if your organizational SOA initiatives contemplate letting development teams choose among multiple programming languages and don't mind making a few trade-offs relying on open source software, Thrift merits a closer look. Its particular protocol and file definition format might not sit well with a few conservative technologists, but in simplicity terms and other areas like versioning support, its benefits make it a strong contender in the SOA market even against more established integration approaches and products.>> You can read this article at: http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1339998,00.html Gervas
