This is a question regularly asked when speaking to clients. Clients wonder what they will see in their system once they have it in place from Cybertill, quite simply they will see nothing.

 

The Cybertill SOAP services module is simply a method to allow parts of your Cybertill EPoS system to be accessible to an external service, i.e. Data-Stream.

 

When you purchase the SOAP services from Cybertill you will be provided with an authentication code and use your domain url (www.mydomain.com)
 

It is important for application development to allow Internet communication between programs.

Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic.

 

A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this.

 

SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.
 

For these reasons it means that Data-Stream or any third party developer can successfully communicate between two completely different systems without the need to be compatible with Cybertill.

 

As Cybertill have written the SOAP rules, third party developers, such as Data-Stream can only consume the services they provide and as such can not damage or affect the Cybertill system in anyway. (We have created a list of Cybertill FAQ's for more clarity)

 

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on eXtensible Markup Language (XML) as its message format, and usually relies on other Application Layer protocols (most notably Remote Procedure Call (RPC) and HTTP) for message negotiation and transmission. SOAP can form the foundation layer of a web services protocol stack, providing a basic messaging framework upon which web services can be built. This XML based protocol consists of three parts: an envelope - which defines what is in the message and how to process it - a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing procedure calls and responses.

 

As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web-service-enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an XML-formatted document with the resulting data (prices, location, features, etc...). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.

 

The SOAP architecture consists of several layers of specifications for message format, message exchange patterns (MEP), underlying transport protocol bindings, message processing models, and protocol extensibility. SOAP is the successor of XML-RPC, though it borrows its transport and interaction neutrality and the envelope/header/body from elsewhere (probably from WDDX)

 

Further information on Cybertill SOAP services can be found on the Cybertill website