The GXtips trend continues to grow. Practical, clear tips to simplify the tasks at work. In this issue, Luís Murillo, member of the Support Team of Artech, explains the facilities offered by GeneXus to generate applications towards a Service Oriented Architecture.

When we talk about Service Oriented Architecture (SOA), we are talking about a   software architecture that facilitates the development of business applications, such as business services with a low level of coupling. The key is the autonomy of components, to divide in modules in order to make them interchangeable. But these components need to be closely communicated because business processes go across modules, each sub-process must hide its whole logics from the rest, only perform a task by communicating through messages, that is, to use services.
 
We refer to modules that fulfill a specific business functionality (e.g. Sales, Procurement) but each module is also built on this architecture (the architect task is defining how far should this architecture go to prevent if from becoming counter-productive). The building of services must be motivated. These services will be in charge of making a well defined functionality available to the application requiring it. In this way, a final application simply orchestrates the execution of a group of these services, adds its particular logic and presents the final user with an interface. Displaying business processes as services is the key to the flexibility of the architecture. This allows other functionality pieces (also implemented as services) to use other services in a natural way, regardless of their physical location. In this way, a system evolves with the addition of new services and improvements, with each service evolving in an independent way. The resulting Service Oriented Architecture (SOA), defines the services that will make up the system, their interactions and the technologies on which they will be implemented.
 
The first problem we face is that we have two clearly defined situations: we will have ‘old school’ and ‘new school’ applications. That is, the applications that were not designed with the vision (or with this architecture) and the new applications we design, which we need to devise with a Service Oriented approach. Therefore, we need to solve not only the problem of “my” application but also I need to enable the communication with the existing applications (legacy), which were not devised in this way.

In order to incorporate these applications to a Service Oriented Architecture, the best is to surround them with a layer to make available that which is required from it in the form of WS. There will be times when we will not have other choice but to access data directly, in order to build that integration layer. For this purpose we have DBRET, DataBase Reverse Engineering Tool, which enables to create Data Views on our KB in order to access the main DBMS.

Additionally, because this layer will be built in an incremental way, we may use the incremental methodology of GeneXus that fits wonderfully with the construction of this layer. In this way also, the easiness of building Web services on GeneXus is appropriate to later make these functionalities available as services, as well as making services available for the company net and the external net when we build our system (now devising them in SOA) . This can be done by simply indicating this in two properties of the GX object that will be WS, Main program in True and Call protocol SOAP.

In order to use features from other Systems/modules/services, we have the  WSDLInspector. This tool defines the WebService that we need to consume in our model automatically as well as all   data types to enable interaction with it. We then simply define variables based on those data types and we will be able to call the WS from any part of our model.

Other useful elements when building our application are the Business components, which enable easy availability of a GX Transaction as WS, so by simply setting a property from the trn. the possibility of having all the trn. logic is enabled as well as the checking of rules towards another application as a WS.
 
Finally, in order to solve the logic layer of the User Interface, we have our GXportal tool for building portals.

In our next GeneXus version (code name Rocha), on which we are already working, we will continue redoubling the bet on this sense, keeping in step with technology and improving what we already have (interacting with tools already existing in the market that are good to solve specific problems, such as BPEL engines).