Service-oriented communications
Service-oriented communications (SOC) technologies are designed to be easily used in the context of service-oriented architectures. These technologies are generally software based and are built more like a business application than a traditional PBX business communications system. Service-oriented communications systems allow their services to participate in business processes. They make their services available to other business applications within and SOA and allow for reuse of the services.
The goal of service-oriented communications is to enable business environments to build communications into their business processes, enabling more streamlined collaboration among people within the business. It typically assumes that certain services are provided in the context of an SOA service provider. This is often in the form of a suite of web services, but may also be attached to other means of sharing the services such as an enterprise system bus (ESB).

The communications part of SOC
Enterprise communications have traditionally been provided by closed, stand-alone PBX systems. Installed in a separate phone room or wiring closet, operated over a different wiring infrastructure, known only by the telecom manager, these systems ran independently from every other aspect of the business.

Today’s business-savvy chief information officers (CIOs) are exploring ways in which information technology can be better leveraged to improve the efficiency and productivity of the enterprise. In practice, CIOs are embracing the concepts of service-oriented architectures and rethinking how the different business systems in use within the enterprise can be designed to allow each system to leverage the benefits of any other system.
The maturing of web service technology has provided a real framework for allowing one system to leverage the services of another according to the principles of a service-oriented architecture. Complex business systems can now work together to deliver solutions in highly customized ways to end users. Increasingly, applications are adapting to the specific needs of users rather than users being forced to adapt to the available functionality of applications.

Web service technology 

As the Internet grew from a forum for sharing information to a marketplace for doing business, a technology matured that allowed computers to transact with each other more easily. Out of these Internet roots, web service technology was born.

The general goal of web services is to construct elements of business logic, services, which can be very easily used by other applications. The services themselves hide the complexity of their business logic from the consumers through simple interfaces that allow the services to be reused in many different applications. The service and the consumer are described as being loosely coupled, an approach that allows complex composite solutions to be developed through leveraging multiple web services.

There are a number of key elements to web service technology…

 XML (eXtensible Markup Language) is the core language of web service technology. It provides a platform neutral way to describe the data associated with any service transaction.
 SOAP (Simple Object Access Protocol) is the preferred means by which an application invokes a web service. The protocol itself is written in XML.
 WSDL (Web Services Description Language) is the specification of the interface that a web service exposes to consumers. It describes the set of operations that the service makes available. The WSDL is also written in XML.
Advantages of web services
 Loosely coupled—the high degree of abstraction that exists between the implementation and the consumption of the service frees the web service client and the web service provider from needing any knowledge of each other beyond inputs and outputs
 Platform neutral—web services can be provided by or invoked on most, if not all, platforms today, even legacy platforms
 Development language neutral—people are developing web services using C/C++, C#, Java, Visual Basic, Python and others
 Standards are architecture neutral—these do not enforce client–server, peer-to-peer or any other model, although practical implementation issues currently drive developers to client–server
 Web services leverage existing standards—standards that are already in place for conventional web server applications, including HTTP, secure sockets and authentication
 Relatively lightweight—so they can be easily deployed to small devices for example PDAs and SmartPhones.

Communication