Advertisment

Web Services & You

author-image
DQI Bureau
New Update

“EDI and VANs of the 70s, as also the integration tech of the 90s, have been confined to the

enterprise



–this makes them inflexible and very expensive”

Dr Suresh Kamath

Advertisment

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.

Advertisment

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.
Advertisment

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

Advertisment