A Domain-Specific Language for Interoperability Between
Object-Oriented and Mainframe Systems
Marcos Rodrigo Sol Souza
Unisys BrazilBelo Horizonte, Brazil [email protected]
Maria Augusta Vieira Nelson
Institute of InformaticsPontifical Catholic University of Minas Gerais Belo Horizonte, Brazil
Abstract
This work presents a domaspecific language (DSL) to in-tegrate object-oriented applications with legacy systems run-ning on mainframes. The DSL offers abstractions to solve re-curring problems encountered when integrating these kinds of systems. It offers to the developer a semantic interface that allows him to concentrate on the implementation of the busi-ness process requirements without having to worry about the complex computational details of establishing the interac-tion between systems. The DSL is implemented using the resources of Ruby, a dynamic object-oriented programming language. In this paper we show the syntax of the DSL, its implementation and a case study of its application.
Keywords interoperability, dospecific language, main-frame systems
1.
Introduction
Information technology is a key factor for the success of many organizations. The dynamic and competitive envi-ronments in which they are inserted demand ever-greater agility in building and updating systems. Domain-specific languages (DSLs) can contribute to increase development productivity and keep the focus on the elements that really add value.
Many organizations keep important business processes in legacy systems. These systems were often built in closed mainframe architectures. Migrating these systems to more current platforms is not always of interest (Knight 1994). These migrations can have high costs and demand profes-sionals who understand the legacy system’s implementation and who are not always available. In other cases, the main-frame systems simply still fulfill the majority of functional and non-functional requirements.
These legacy systems are usually inserted in heteroge-neous environments and must coexist with other software systems. There are several approaches for interoperability between legacy systems and new object-oriented systems. Service-oriented architectures have been used successfully
in recent years, unlike other less successful past attempts like CORBA (Common Object Request Broker Architecture)and the JCA (Java Connector Architecture) specification.
Much of the work for achieving interoperability is re-lated to mapping data and communicating across networks. Specifically, to achieve interoperability between legacy sys-tems and object-oriented syssys-tems, one must map untyped text messages that contain the inputs and outputs of pro-grams in the legacy system to classes in the object-oriented system. This activity involves many phases related to the type conversion between the two systems.
Building applications that must deal with interoperability issues takes a long time. The tasks are usually repetitive and draw the developers’ attention away from the problem domain. Using a DSL to abstract away the complexity of achieving interoperability between object-oriented systems and legacy systems is a good approach for faster and more productive development.
Many legacy systems in mainframes were implemented in COBOL. In the case of Unisys mainframes, the interop-erability with other systems happens through the exchange of messages. These messages represent a data structure that the COBOL program can understand. The messages must be manually converted to the corresponding object-oriented model. The mapping leads to lowered flexibility to deal with changes in the legacy system. A new process or even a new attribute can have an impact on the object-oriented system that depends on the legacy system.
1.1 SOA approach
Service Oriented Architectures (SOA) are becoming a stan-dard for achieving interoperability among complex systems. However, the DSL presented in this work differs from SOA in some aspects. In many computational ecosystems, service buses help with integration and allow great scalability for the environment (Krafzig et al. 2004).
SOA usually imply some sort of adaptation in the soft-ware systems that wish to publish and consume services.
These implementations can be aided by middleware or by direct intervention over the application (Oberle 2006).
The use of SOA requires a clear mapping of the busi-ness rules and the knowledge of where they can be found in the system. This is often not available in legacy systems, because the rules can be scattered across several programs. The approach proposed in this work differs from the service-oriented approach because it sees the legacy system as a black box that has a set of working inputs and outputs, with-out concerning itself with the business rules behind it (Hur-witz et al. 2006).
2.
Providing abstractions for interoperability
A large part of the difficulty in building applications that need to communicate with legacy systems lies in the lack of good interoperability abstractions. Developers spend a long time writing code that performs simple tasks like mapping input/output messages to object-oriented concepts, instead of dedicating time to effectively solve the real problems re-lated to the application domain. Implementing communica-tion is also an important aspect.No matter what technologies and standards are used to achieve interoperability, the mapping of data and interfaces between the systems is usually static. This leads to replica-tion of data representareplica-tion in both systems, even if transient. The replication impacts negatively on the maintenability of the application, because a change that includes new data in one of the system’s interfaces must be replicated across the entire code(Bisbal et al. 1999).
2.1 Communication protocol
Interoperability demands the definition of a communication protocol between the platforms. Though mainframes have their own communication protocols like the Burroughs Net-work Architecture (BNA), they currently natively support the TCP/IP protocol, which makes this the most natural choice (IBM 1999). In the case of Unisys mainframes, it is also possible to combine the TCP with the Custom Connec-tion Facility (CCF). The CCF provides a way to direct pack-ages that arrive at a specific TCP port to a central program. This program will direct the message to its destination and provide a reply to the caller.
2.2 Message exchange
Communication between programs is done through asyn-chronous message exchange, as required by the mainframe. These messages carry data in a previously defined format and represent the actions that must be executed in the legacy system. Messages also contain execution parameters.
The main body of the message is composed of a sequence of elements. First comes the program identifier, which in the case of programs managed by the Unisys Transaction
Server (COMS) is called TRANCODE, a unique attribute
that identifies each program managed by the mainframe cen-tral controller. Next comes the action. The action determines
what the program must execute when receiving the message. Actions can be of many kinds, from common actions of a CRUD (create-read-update-delete) to complex actions like emitting reports or performing simulation computations. The remainder of the message contains the layout of the mes-sage that the program expects to receive. In our case, this is a COBOL segment. The complexity of this kind of data structure must be handled by the object-oriented program that needs to communicate. This implies that compaction al-gorithms must be implemented, and vector or matrix field groups must be interpreted. In COBOL, these field groups
are calledoccurs(Unisys 1999)(Unisys 1995).
3.
Mapping domain expertise
The main goal of this DSL is to provide an interface to integrate programs without the need for the developer to know about the issues involved in interoperability. He must be capable of integrating a legacy system with his object-oriented system with nothing but the syntax offered by the DSL.
3.1 Abstracting the interoperability complexity
The first step towards arriving at a syntax for the DSL was to describe a common code fragment to perform a simple integration between a legacy program and its representation in an object-oriented system. The object model representing the domain of the program that will be used (Krishnamurthi 2003) needs to be described. Listing 1 shows a class that represents the domain of debits in loan contracts. The pro-gramming language used in the listings is Ruby (rub 2000). The name of an instance variable starts with @ in Ruby.
Listing 1. Problem domain class
2 # D e b i t s c l a s s w i t h l e g a c y s y s t e m a t t r i b u t e s 3 c l a s s D e b i t s 5 @ t r a n c o d e 6 @ a c t i o n 7 @ c o n t r a c t i d = 0 8 @ c u s t o m e r i d = ” ” 9 @name = ” ” 10 @year = 0 11 @fine = 0 . 0 0 12 @ l o c a t i o n c o d e = 0 13 @ s t a t u s = [ ] 15 a t t r a c c e s s o r : t r a n c o d e , : a c t i o n , : c o n t r a c t i d , 16 a t t r a c c e s s o r : c u s t o m e r i d , : name , : y e a r , : f i n e , 17 a t t r a c c e s s o r : l o c a t i o n c o d e , : s t a t u s 19 end
Another class would be necessary to map the messages from each direction into the class defined above. Listing 2 shows how this function would be written.
Listing 2. A class to query the legacy system
2 d e f f i n d B y C o n t r a c t ( c o n t r a c t i d ) 4 t r a n c o d e = ” V034741001 ” 5 a c t i o n = ”QRY” 6 m s g i n = t r a n c o d e + a c t i o n + c o n t r a c t i d 8 c o m p r e s s u t i l i t y = C o m p r e s s U t i l i t y . new 10 m s g i n = c o m p r e s s u t i l i t y . p a c k ( m s g i n , 1 3 , 2 0 ) 11 c o n n = M a i n f r a m e . c o n n e c t i o n . new : h o s t , : p o r t 12 m s g o u t = c o n n . s e n d r e c e i v e ( m s g i n ) 13 m a p p e d O b j e c t = D e b i t s . new 15 m s g o u t = 16 c o m p r e s s u t i l i t y . u n p a c k ( m s g o u t , 1 3 , 2 0 ) 18 m s g o u t = 19 c o m p r e s s u t i l i t y . u n p a c k ( m s g o u t , 6 6 , 7 1 ) 21 m a p p e d O b j e c t . t r a n c o d e = m s g o u t [ 0 , 1 0 ] 22 m a p p e d O b j e c t . a c t i o n = m s g o u t [ 1 0 , 1 3 ] 23 m a p p e d O b j e c t . c o n t r a c t i d = m s g o u t [ 1 3 , 2 5 ] 24 m a p p e d O b j e c t . name = m s g o u t [ 2 5 , 6 1 ] 25 m a p p e d O b j e c t . y e a r = m s g o u t [ 6 1 , 6 5 ] 26 m a p p e d O b j e c t . f i n e = m s g o u t [ 6 5 , 6 6 ] 27 m a p p e d O b j e c t . l o c a t i o n c o d e = m s g o u t [ 6 6 , 7 1 ] 28 m a p p e d O b j e c t . s t a t u s = A r r a y . new ( 4 ) 29 m a p p e d O b j e c t . s t a t u s [ 0 ] = m s g o u t [ 7 1 , 7 4 ] 30 m a p p e d O b j e c t . s t a t u s [ 1 ] = m s g o u t [ 7 4 , 7 7 ] 31 m a p p e d O b j e c t . s t a t u s [ 2 ] = m s g o u t [ 7 7 , 8 0 ] 32 m a p p e d O b j e c t . s t a t u s [ 3 ] = m s g o u t [ 8 0 , 8 3 ] 34 r e t u r n m a p p e d O b j e c t 35 end 36 end
Finally, a new class could be written to achieve interoper-ability using the above-defined classes. Listing 3 shows these classes being used.
Listing 3. Execution of a query in the legacy system
1 c l a s s Foo 2 d e f main 3 d e b i t s Q u e r y = D e b i t s Q u e r y . new 4 o b j = d e b i t s Q u e r y . f i n d B y C o n t r a c t ( 1 2 3 4 ) 5 p u t s o b j . name 6 end 7 end
Except for the 7 lines of code from listing 3, all code was written solely for the purpose of interoperability. There is code to create a class representing the interface of the legacy system, code to create connections with the mainframe, code to compress and uncompress messages, and lots of code to map data from the mainframe to the object.
One of the goals of the DSL is exactly to abstract away most of the complexity of interoperability so that the pro-grammer can focus on the implementation of the business rules (Fowler 2005). Given this premise, the DSL must pro-vide a way for the programmer to access any program in the legacy system by using only the last code fragment; all the rest must be a responsibility of the DSL.
3.2 Defining a grammar
The next step is the definition of a grammar so that the DSL can provide the data required for interoperability without burdening the programmer (Fernandez 2007). The code frag-ment that resulted from the previous analysis was again ex-amined to find the functions that should be supported by the DSL, according to Listing 4:
Listing 4. Functionalities of the analyzed code
1 c l a s s Foo 2 d e f main 4 # C r e a t e s an i n s t a n c e o f t h e c l a s s D e b i t s Q u e r y 5 d e b i t s = D e b i t s Q u e r y . new 7 # E x e c u t e s an a c t i o n i n t h e l e g a c y s y s t e m 8 # p a s s i n g an i n p u t a t t r i b u t e 9 o b j = d e b i t s . f i n d B y C o n t r a c t ( 1 2 3 4 ) 11 # G e t s and m a n i p u l a t e s t h e a t t r i b u t e s r e t u r n e d 12 # by t h e l e g a c y s y s t e m 13 p u t s o b j . name 14 end 16 end
For the programmer, the DSL should support the follow-ing actions:
•Create an instance of the object
•Execute the actions supported by the legacy system
•Inform input parameters for the actions
•Obtain and use the results of executing an action
Based on this analysis, a syntax was defined to simplify the process. First, we define a key that indicates which pro-gram must respond to the requests in the legacy system. This
key was calledtrancode. By convention, any method with
a three-character name represents the execution of an ac-tion in the legacy system. The basis for this decision lies on the practices of work environment where the study was performed. In this environment, it is common practice to use three letters to name actions. Finally, it was defined that the input or output attributes will be represented by their own names. When used in the left-hand side of an assignment, the attribute will represent data that must be sent to the main-frame. The same attribute, when used in the right-hand side of an assignment, will represent data to be read from the mainframe.
Based on this analysis, Listing 4 was rewritten, establish-ing the syntax of the DSL to be as shown in Listestablish-ing 5:
Listing 5. DSL syntax
1 # D e f i n e s t h e p r o g r a m i n t h e l e g a c y e n v i r o n m e n t 2 t r a n c o d e : V034741001
4 # D e f i n e s an i n p u t p a r a m e t e r 5 c o n t r a c t i d = 1234
7 # E x e c u t e s an a c t i o n named q r y ( t o q u e r y ) 8 # i n t h e p r o g r a m 9 q r y 11 # W r i t e s t h e f i e l d name , t h e r e s u l t o f t h e q u e r y 12 p u t s name
4.
Implementation strategy
4.1 Formal definition of the DSL syntax
The DSL used in this work was written in the Ruby program-ming language. Ruby was selected because it is a dynamic language that allows behaviors to be changed by overloading methods of its kernel. Ruby also offers excellent support for metaprogramming.
The implementation of the DSL follows the approach
known as Class macro. In this approach, the DSL is built
from methods in some base classes. Subclasses can use these methods to modify their own behavior or that of their own subclasses (Fernandez 2007). Another benefit of this ap-proach that is used by the DSL is the ability to change an object’s behavior dynamically by executing a command.
To use the DSL, the programmer must create a class that inherits from the DSL class. This class contains the gram-mar defined by the DSL. When executing an instance of the object that inherited from the DSL, the constructor will ini-tialize the necessary data structures and will create a con-nection with the mainframe. Next, it creates the attributes that are required to store the data during the execution of the DSL, which include the current program on the legacy system that the DSL refers to. The following step is to call the private method that updates the input and output data structures according to the specification found in the domain repository. This repository contains the descriptions of the communication interface of each program from the legacy system. The repository is created automatically by reading reports about the programs available in the mainframe. — O repositrio tambm mantm informaes sobre a tipagem dos atributos no sistema legado. A DSL utiliza essas informaes para realizar o casting dos dados para sua representao equiv-alente no sistema legado. —
Theupdate internal structuresmethod is shown in List-ing 6.
Listing 6. Updating internal structures
1 d e f u p d a t e i n t e r n a l s t r u c t u r e s 2 @in = @specs 3 @out = @specs 4 @ s o r t e d i n = 5 @in . s o r t{ |x , y| x [ 1 ] [ 0 ] <=> y [ 1 ] [ 0 ]} 7 @ s o r t e d i n . d e l e t e i f { |e| e ==n i l} 8 @ s o r t e d o u t = 9 @out . s o r t{ |x , y| x [ 1 ] [ 0 ] <=> y [ 1 ] [ 0 ]} 11 @ s o r t e d o u t . d e l e t e i f { |e| e ==n i l} 12 end
This method is also called every time the system executes a method that substitutes the current DSL program for an-other. After assigning all message specifications, arrays are created with the fields in the order in which they will be send and received by the mainframe.
Every time the trancode command is executed, the pro-gram name received as parameter will be used in a query to the knowledge repository. If there is information about the program in the repository, a specification will be returned and used to update the data structures, configuring the cur-rent instance to the context of the new program. This com-mand is defined in the method shown in Listing 7.
Listing 7. Macro to identify the context
1 d e f t r a n c o d e ( t r a n c o d e )
2 @specs = R e p o s i t o r y . t r a n c o d e s [ t r a n c o d e . t o s y m ] 3 @ t r a n c o d e = t r a n c o d e
4 u p d a t e i n t e r n a l s t r u c t u r e s 5 end
Once the current program is defined, the programmer can use the other commands from the DSL syntax, which are as-signment of a value to an attribute, reading an attribute, and execution of an action. This is implemented by overriding
methodKernel.method missing. This method belongs to the
Ruby language kernel. Once overridden, it will intercept ev-ery call to a nonexistent method on the object that inherited from the DSL (rub 2000).
When methodmethod missingis called, the DSL verifies
in the current specifications if the method that failed repre-sents any program attributes. If so, it verifies if the failure was caused by an attempt to assign a value to or read a value from a nonexistent attribute. If it’s an attempt to read, the value corresponding to the attribute that is in the data struc-ture that stores the output values will be returned dynami-cally to the caller. If the call is an assignment, then the value will be assigned to the data structure that stores the input values so that it can be sent later to the legacy system. This implementation also verifies if the name of the method has only three letters, according to DSL convention. In this case, it will send the corresponding action to the program in the legacy system, passing as argument a message containing all the data that were assigned by the programmer. When a reply message is received from the legacy system, the mes-sage is parsed and the values are dynamically assigned to the corresponding attributes.
Overriding the method Kernel.method missing is what
makes this approach possible and flexible. Listing 8 shows the implementation of this method for this DSL (rub 2000).
Listing 8. Implementation of method missing
1 d e f m e t h o d m i s s i n g ( m e t h I d , ∗a r g s ) 2 # v e r i f i e s i f i t i s a g e t t e r
3 i f m e t h I d . i d 2 n a m e = ˜ / = $ / &&
4 @in [ m e t h I d . i d 2 n a m e [ 0 , m e t h I d . i d 2 n a m e . s i z e − 1 ] 5 . t o s y m ]
7 r e t u r n 8 @ d a t a i n [ m e t h I d . i d 2 n a m e [ 0 , m e t h I d . i d 2 n a m e . s i z e−1] 9 . t o s y m ] 11 # v e r i f i e s i f i t i s a s e t t e r 12 e l s i f @out [ m e t h I d . i d 2 n a m e . t o s y m ] | | 13 @in [ m e t h I d . i d 2 n a m e . t o s y m ] 14 i f @ d a t a o u t [ m e t h I d . i d 2 n a m e . t o s y m ] && 15 @ d a t a o u t [ m e t h I d . i d 2 n a m e . t o s y m ] ! = n i l 16 r e t u r n @ d a t a o u t [ m e t h I d . i d 2 n a m e . t o s y m ] 17 e l s e 18 i f @in [ m e t h I d . i d 2 n a m e . t o s y m ] 19 r e t u r n @ d a t a i n [ m e t h I d . i d 2 n a m e . t o s y m ] 20 e l s i f @out [ m e t h I d . i d 2 n a m e . t o s y m ] 21 r e t u r n @ d a t a o u t [ m e t h I d . i d 2 n a m e . t o s y m ] 22 e l s e 23 r a i s e N o M e t h o d E r r o r 24 end 25 end 26 e l s e 27 # v e r i f i e s i f i t i s an a c t i o n 28 r a i s e N o M e t h o d E r r o r 29 u n l e s s m e t h I d . i d 2 n a m e = ˜ 30 / ˆ (\w{7 , 1 0} \w{1 , 4} | \w{1 , 4}) $ / 31 p a r a m s = {} 32 p a r a m s = a r g s [ 0 ] i f a r g s . l e n g t h > 0 33 e x e c u t e ( m e t h I d . id2name , p a r a m s ) 34 end 35 end
The overridden method receives as parameter the name of the method that was not found and that represents the attempt to use some DSL command, plus a list of pointers to the arguments to this command. The system checks if a read attempt was made, and if the appropriate attribute exists in the input specification. If so, the current value of the attribute is returned. To achieve this, a regular expression detects whether the last character of the name of the received method is ’=’, which the Ruby language concatenates by convention to the argument that represents the method name. If it isn’t a read attempt, the system checks if a write attempt was made. If there is a compatible attribute, then the value of the first argument to the method is associated to the key of the hash that stores the input attributes.
If both checks above fail, the system checks if the method name has only 3 letters, in which case it calls a method that will send an execution request to the legacy system.
If none of the above conditions are true, the system con-siders it a syntax error, raising an exception that will inform the user that the attempted command is not valid in the cur-rent DSL context.
The method responsible for sending the executed action to the legacy system assembles an input message to that system according to the specifications. This message will be sent through the connection created by the constructor of the parent object. When a reply to this message is received from the legacy system, it is parsed and the values it contains are assigned to the corresponding attributes.
5.
Applying the DSL
We performed a case study consisting of rewriting a real application with the proposed DSL. The chosen application is responsible for simulating real estate loan financing for a financial institution. All business rules for this application already existed in a legacy system, but the client required a web-based interface with high usability, which would allow the institution’s customers to do their own loan simulations. This application was originally implemented using the Java programming language and a large portion of its code was written with the sole purpose of achieving interoperability with the legacy system.
When using this application, the user provides some data such as birth date, income, and some characteristics of the property for which he wishes to acquire a loan. This infor-mation is sent to the legacy system, which selects the best type of loan for the client’s profile, from among many avail-able types. At first, the legacy system assumes that the con-ditions for the loan are those that will maximize the value of the loan. The results of the simulation calculations are displayed to the user. The user can change some of the con-ditions for the loan such as duration and initial value. In this case, he is taken to a screen where a new form for data entry is shown. The changes are sent to the legacy system and new values are returned to the user.
When using the DSL, all of the code related to interoper-ability was eliminated, making the implementation fully ori-ented to the problem domain. Listing 9 shows how the DSL can be used to represent the entire flow described above.
Listing 9. Modeling the simulator flow
2 S i m u l a t o r F l o w < DSL 3 # I d e n t i f i e s t h e p r o g r a m i n t h e 4 # l e g a c y e n v i r o n m e n t 5 t r a n c o d e : s i m u l a t o r 7 # I n i t i a l i z e s a t t r i b u t e s 8 b i r t h d a t e = ’ 2 2 / 0 2 / 1 9 8 3 ’ 9 i n c o m e = 2 0 0 0 . 0 0 10 p r o p e r t y v a l u e = 5 0 0 0 0 . 0 0 12 # E x e c u t e s t h e a c t i o n ( s i 1 ) t h a t c o r r e s p o n d s 13 # t o t h e f i r s t s t e p i n t h e s i m u l a t i o n f l o w 14 s i 1 16 # C h o o s e s t h e f i r s t p r o d u c t a s t h e 17 # s i m u l a t i o n t a r g e t 19 p r o d u c t c o d e = p r o d u c t s [ 0 ] 21 # E x e c u t e s t h e a c t i o n ( s i 2 ) t h a t c o r r e s p o n d s 22 # t o t h e s e c o n d s t e p i n t h e s i m u l a t i o n f l o w 23 s i 2 25 # W r i t e s t h e i n s t a l l m e n t v a l u e o f t h e l o a n 26 p u t s ” I n s t a l l m e n t v a l u e : ${i n s t a l l m e n t}” 28 # C h a n g e s t h e d u r a t i o n o f t h e l o a n 29 t e r m = 180
31 # E x e c u t e s t h e a c t i o n ( s i 2 ) t h a t c o r r e s p o n d s 32 # t o t h e s e c o n d s t e p i n t h e s i m u l a t i o n f l o w 33 s i 2 35 # W r i t e s t h e i n s t a l l m e n t v a l u e a f t e r t h e c h a n g e 36 # o f t h e l o a n d u r a t i o n 37 p u t s ” I n s t a l l m e n t v a l u e : ${i n s t a l l m e n t}” 38 end
6.
Conclusion
This work presented a language specific for the domain of interoperability between object-oriented systems running on microcomputers and legacy systems running on mainframes. The legacy applications are important to organizations, be-cause they contain systems that are essential to their busi-nesses. However, the information in these systems needs to be accessed by users through varied interfaces, including the web. This creates a constant need for new applications that need to communicate with the legacy systems.
We conclude that using a DSL for interoperability be-tween legacy and object-oriented systems is a good approach to increase development speed and improve maintainability of this kind of application.
Our results encourage the use of the proposed approach, because is was possible to abstract away a great portion of the complexity inherent to interoperability, such as commu-nication, message composition and object assembly.
Besides productivity, another important aspect of this ap-proach is the ability given to the developer to describe with greater semantics the transformations in his business pro-cesses, using the DSL syntax.
There are a few limitations to the DSL approach pre-sented here. First, the focus of this work was the legacy
sys-tems developed in COBOL that run onUnisysmainframes. It
maybe necessary to adapt the DSL to deal with systems writ-ten in other languages or in other hardware platforms from different manufacturers. The second limitation is related to the fact that this DSL is internal to Ruby and its syntax can never abandon the principles of its host language.
However, the gains in productivity, its simple syntax, the transparency in the interoperability and the shift in focus to business rules are significant advances.
References
Ruby doc. 2000. URLhttp://ruby-doc.org.
Jes´us Bisbal, Deirdre Lawless, Bing Wu, and Jane Grimson. Legacy information systems: Issues and directions. IEEE Soft-ware, 16(5):103–111, /1999.
Obie Fernandez. Agile DSL development in Ruby. 2007. URL
http://tinyurl.com/69ajec.
Martin Fowler. Language workbenches: The killer-app for domain specific languages? June 2005. URL
http://tinyurl.com/7ppah.
Judith Hurwitz, Robin Bloor, Carol Baroudi, and Marcia Kaufman. Service Oriented Architecture For Dummies. 2006.
IBM.SNA APPN Architecture Reference. 1999.
Robert Knight. Don’t shoot the mainframe. Software Magazine, April 1994.
Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA: Service-Oriented Architecture Best. Prentice Hall PTR, 2004. Shriram Krishnamurthi. Programming Languages: Application
and Interpretation. Brown University Press, 2003.
Daniel Oberle. Semantic Management of Middleware. Springer, 2006.
Unisys.COBOL ANSI-85 Programming Reference Manual - Basic Implementation. 1995.
