This page provides an introduction to Web Services with the Genero Web Services Package (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.
Generally speaking, Web services are a standard way of communicating between applications over an intranet or Internet. They define how to communicate between two entities:
A server that exposes services
A client that consumes services
A server exposes 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 is a function written in Genero BDL, and it is published on the server. This function retrieves the stock value for the stock symbol passed in, and returns it.
The Web service client application calls the function as if it were a local function. It passes the stock symbol in to the function, and stores the returned value in a variable. If the Web Service operation is named WebService_StockQuotation_getQuote and the local variable is svalue, the Web Service is called as follows:
01 LET svalue = WebService_StockQuotation_getQuote( "MyStockSymbol" )
For detailed instructions:
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; 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 the 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. It 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 contains some 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, and 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 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 think how your services can be reused by others.
Security will likely play a larger role than it did previously with existing in-house application infrastructures using 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. Interoperability.The Genero Application Server is required to manage your Web Services in a deployment environment. Unless you are interested in testing deployment issues, it is not required for Web Services development.
Important: Your applications should include the following line at the top of each module to import the Genero Web Services Extension library named com:
import com
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 Genero Web Services package supports the WSDL 1.1 specification of March 15, 2002 as well as some previous specifications.
The standards involved in what is commonly called "Web services" include:
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 a server and the client. It defines the XML data flow between the server and the client. The "StockQuote" service mentioned in the Concepts section exchanges 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 provide all the information required to communicate with the SOAP server.
Genero Web Services package 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 Web Services Style options available for created GWS web services are WS-I (Web Services Interoperability organization) compliant: