Web services technology is a major step in the world of collaboration over the Internet. In the beginning, computer apps were confined to a handful of people within an organization. With development in distributed computing and client-server technology, the community was enlarged to include the users of these applications. The merging of communication and computer technologies paved the way for the Internet, and with the Internet, applications, information, data were opened up for all those who care to access them—application developers, application users within the enterprise, partners involved with the organization, and customers.

The Web browser, which all users interact with to access and control the applications and information sharing, however does not reveal to them the complexities and costs that are embedded in providing the facility. For example, a typical usage would involve accessing a Web site, creating an account, accessing the account and providing relevant information, browsing a catalogue, choosing items for purchase, selecting a delivery option, selecting a payment option, providing payment details, and confirming the transaction (in case the usage involves only browsing, then one may not go through some of these steps). The visible result of this interaction is the delivery of the item(s) ordered at the users’ location.

Collaboration and architecture
With all the hype about the Internet, Java, XML, COM+, application servers, application integration and legacy host connectivity, the fact remains that there is no cost-effective way to implement a collaborative set of apps that can address the scenario described above. The collaboration is painful, requires large investment to develop and maintain the systems, and is almost always unique, even when the application scenario remains the same.

The basic problem is the underlying technology that each of these organizations uses to implement the solution for their business, which also forms part of the collaboration needs for the scenario.

Assuming that apps run by same or different organizations provide a feature called "service on demand", application "services" can be requested as and when required, and these application services will satisfy the request anytime, anywhere, and on any device. Some points to be noted are:

• Services will be delivered electronically (not manual or other models);
• Apps can not be tightly coupled;
• Services availability is 24*7*365; and
• Service delivery should be enabled on any device as target.

The architecture of application systems that support the above features is called service-oriented architecture (SOA). While technologies for SOA have existed for long, implementation of these has never been done with service orientation. RPC, or remote procedure call, which allows applications to invoke remote functions, existed in the 70s. RPC provides independence from operating systems, languages used, network protocols and hardware platforms. RPC has further evolved into more function-rich protocols such CORBA, and RMI, which allow invoking object methods in addition to traditional functions as in the RPC. Architectures that support components that can be assembled to create applications also has been evolving such as COM/DCOM/COM+ from Microsoft and Java Beans, Enterprise Java Beans from Java based technologies from SUN.

XML based protocols have made the interoperability smoother. The core transport protocol for all these is the TCP/IP.

The author is chief technology officer of TranSys Technologies. The full column can be accessed at www.dqindia.com