Web Services & VSE: Fit Into a Modern Systems & Applications Infrastructure

by Rich Smrcina
June 1, 2005

Code reuse is a key concept I learned in college-level programming classes. The technique initially was used when coding subroutines in programs. It evolved to using the inter-program communications feature of a programming language to write separate programs that could be used from the main program. The result was the ability to build a set of tools that could be used by any future program written. This practice remains prevalent today, and programmers usually have an arsenal of callable programs that perform some function that’s integral to their systems.

 

Web Services Background

As client/server systems became vogue, inter-program communications evolved to inter-systems communications over a network. This evolution took various forms, including:

• The Open Group’s Distributed Computing Environment (DCE) architecture - Remote Procedure Call (RPC), which Sun developed as part of its Open Network Computing (ONC) architecture
• Microsoft’s Component Object Model (COM) and Distributed COM (DCOM), modeled after the RPC in DCE
• The Object Management Group’s Common Object Request Broker Architecture (CORBA).

 

DCOM and CORBA are somewhat limited in that the same implementation of each protocol is typically needed to communicate between systems. For DCOM, this means Windows; for CORBA, each system requires the same ORB broker.

Web Services is an implementation of an overall concept called Service-Oriented Architecture (SOA). Since Web Services is based on open standards, it compensates for some of the weaknesses in DCOM and CORBA. An SOA can be implemented in many ways; for instance, both MQ Series and CICS Transaction Gateway can be considered an SOA. An SOA is more commonly thought of as being tied to Web Services. In turn, Web Services is usually thought of in terms of the implementation called Simple Object Access Protocol (SOAP). (A full description of SOAs, Web Services, and SOAP is beyond the scope of this article. For more information, see the resources listed at the end of this article.)

In Web Services, the “service” (a.k.a. provider) provides a specific function. The consumer uses the service and requests it from the provider. The provider implements the service for any consumer that wishes to use it. The service implementation is transparent to the consumer; the consumer doesn’t care how the provider implements the service. The consumer and provider can be running any operating system and can implement their respective roles in any programming language. These details aren’t known, nor are they divulged each to the other. Service implementation can be a simple mathematical calculation or a complex operation involving file or database operations or even invoking other Web Services. The communications between the provider and consumer is through HTTP-based request and response messages.