This page provides an introduction to Web Services with the Genero Web Services Extension (GWS). It is intended to help those using GWS for the first time to understand basic Web Services concepts, and to quickly start their development with the Genero tools.
Summary:
In general, Web services are a standard way of communicating between applications over an intranet or the Internet. They define how to communicate between two entities:
A server that exposes services
A client that consumes the services
For example, a server could expose a "StockQuotation" service that responds to an operation "getQuote". For the "getQuote" operation, the input message is a stock symbol as a string, and the output message is a stock value as a decimal number.
The "getQuote" operation could be a function written in Genero BDL and published on the server. This function retrieves the stock value for the stock symbol passed in, and returns this stock value.
On the client side, the Web service client application calls the function as if it were a local function, passing the stock symbol and storing the returned value in a variable. For example, if the Web Service operation is named WebService_StockQuotation_getQuote and the local variable is svalue, you would call the Web Service as follows:
01 LET svalue = WebService_StockQuotation_getQuote( "MyStockSymbol" )For more information on the steps for creating a Web Service server or client, refer to the Tutorial: Writing a GWS Server application and Tutorial: Writing a Client application respectively.
Service Oriented Architecture (SOA) is a philosophy of how to connect systems and exchange data to solve business problems. Rather than concentrating on a specific task or transaction, SOA addresses how to use data from various sources, reduce human work, and mitigate the effects of change in a business process and its supporting systems.
The SOA defines the services to be provided, and Web Services are the means of implementing those services. Web Services provide a platform-neutral technology to connect multiple systems in a flexible manner, where the platform-neutrality helps insulate a SOA from changes to the underlying systems.
Web Services work by answering requests for information and returning well defined, structured XML documents. Because XML is simple text and Web Services can be invoked via the hypertext transfer protocol (HTTP), it does not matter what platform runs the Web Service, or what platform receives the XML document.
An SOA’s resilience to change is accomplished by adhering to good Web Services design practices:
Web Services tell exactly how to ask for the information in an XML document written using the Web Services Descriptive Language (WSDL). This self-describing document describes the service the Web Service will perform and how to form the request for its data. Each Web Service must have an associated WSDL document, so that developers and applications know what to expect from the Web Service, and how to invoke it.
Developing an SOA and moving to Web Services is an iterative and evolutionary process, and requires work and diligent design. When switching to Web Services from another integration method, it is recommended to initially focus on shorter term business benefits, targeting an SOA and Web Services project that has tangible goals with measurable benefits.
Once an SOA starts to contain useful services, these services can be arranged together in a workflow that automates a business process. Web Services can be reused to answer new questions, implemented as new business services in an SOA. A well-defined Web Service does not contain business logic or business process information. Because each Web Service in an SOA can be called individually to perform a specific task, they can be arranged (orchestrated) together to perform many different business functions. As a result, companies with a mature SOA in place can change business processes through configuring of the orchestration software as opposed to programming individual links between systems.
When creating a Web Service, you not only have to think of the immediate task at hand, but you should also consider growth. You likely want the Web Service to be flexible; to be able to handle different types of input. Prepare the Web Service for what is probable. Developers should think bigger than the needs of a single application. You should think of reusing existing services, and imagine how your services can be reused by colleagues. Security will likely play a larger role than it did previously with existing in-house application infrastructures with programmed links between systems; you will need to become versed in security issues.
Keep the goals of SOA in mind when designing and coding Web Services: flexibility, reusability, and interoperability.
Web services are platform-independent and programming language-independent. The World Wide Web consortium defines the Web services standards. For more information about these standards, refer to the "Web services" section of their web site at http://www.w3.org. The Four J's Web Services Extension supports the WSDL 1.1 specification of March 15, 2002 and some previous specifications.
The standards involved in what is commonly called "Web services" are:
XML (Extensible Markup Language) defines a machine-independent way of exchanging data. For example, an XML representation of the following BDL data structure:
01DEFINE Person02RECORD Attribute (XMLName="Person")03FirstName VARCHAR(32) Attribute (XMLName="FirstName"),04LastName VARCHAR(32) Attribute (XMLName="LastName"),05Age INTEGER Attribute (XMLName="Age")06END RECORD
could be:
<Person> <FirstName>John</FirstName> <LastName>Smith</LastName> <Age>35</Age> </Person>
The record definition uses a Genero version 2.0 feature that allows you to specify XML attributes for data types.
XML Schema defines the elements, entities, and content model of an XML document. For example, for the above document, the schema could say that the XML document contains an element "Person", and that each "Person" contains one and only one element "FirstName", "LastName", and "Age". The XML Schema has additional capabilities, such as data type control and content restrictions.
An XML Schema allows an XML document to be validated for correctness.
SOAP (Simple Object Access Protocol) is a high-level communication protocol between the server and the client. It defines the XML data flow between the server and the client. The "StockQuote" service mentioned in the Concepts section will exchange messages using the following syntax:
Request
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getQuote>
<stockSymbol>MyCompany</stockSymbol>
</getQuote>
</soap:Body>
</soap:Envelope>
Response
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getQuoteResponse>
<stockValue>999.99</stockValue>
</getQuoteResponse>
</soap:Body>
</soap:Envelope>
SOAP relies on a lower-level protocol for the transport layer.
Genero Web Services use SOAP over HTTP, and can also perform low-level XML and TEXT over HTTP communications on the client side. This allows communication between applications using the core Web technology, taking advantage of the large installed base of tools that can process XML delivered plainly over HTTP as well as SOAP over HTTP.
The WSDL (Web Services Description Language) file describes the services offered by a server. It contains:
A WSDL description is sufficient to get all the information required to communicate with the SOAP server.
Genero Web Services Extension provides a tool, fglwsdl, that enables Genero client applications to obtain the WSDL description of a Web Service.
HTTP (Hypertext Transfer Protocol) is the set of rules for exchanging files (text, graphic images, sound, video, and other multimedia files) on the World Wide Web.
The following Styles provided by GWS for a Web Service are WS-I compliant (Web Services Interoperability organization):
In addition, the RPC Style Service (RPC/Encoded) is provided for backwards compatibility.