|
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