A Domain Specific Modeling Framework for Secure Network ...

A Domain Specific Modeling Framework for Secure Network Applications Hiroshi Wada (Ph.D student) and Junichi Suzuki (advisor) Department of Computer Science University of Massachusetts, Boston {shu, jxs}@cs.umb.edu 1. Introduction Software modeling technologies have matured to the point where they can offer significant leverage in all aspects of software development. Given modern modeling technologies, the focus of software development has been shifting away from implementation technology domains toward the concepts and semantics in problem domains [1]. Domain specific languages (DSLs) provide a promising solution to directly represent and implement domain concepts [2]. DSLs are visual or textual languages targeted to particular problem domains, rather than generalpurpose languages that are aimed at any software problems. Various DSLs have been proposed and used for describing, for example, security aspects of network applications (e.g., role-based access control, data encryption and secure network links) [3, 4]. Although many experience reports have demonstrated DSLs can improve software development productivity (e.g., [5]), existing DSLs are supported only by specific tools and frameworks; there are few generic frameworks supporting arbitrary DSLs. This Ph.D. research investigates a generic model-driven development (MDD) framework that supports arbitrary DSLs, and empirically evaluates a series of techniques to develop such a framework. Steps towards creating the proposed framework include investigating a generic foundation to handle arbitrary DSLs; strategies, principles and tradeoffs in different DSL designs (e.g., DSL syntax and semantics); building blocks for modeling and programming domain concepts; transformation strategies from domain concepts to the final (compilable) source code; and development processes to leverage the proposed framework well.

2. Modeling Turnpike This project proposes and investigates an MDD framework, called Modeling Turnpike (mTurnpike). mTurnpike allows developers to model and program domain concepts in arbitrary DSLs and to transform them to the final (compilable) source code [6]. Leveraging the notions of UML metamodeling and attribute-oriented programming, mTurnThis work is supported in part by OGIS International, Inc., Central Research Institute for Electric Power Industry and Electric Power Development Co., Ltd.

pike provides an abstraction to represent domain concepts at the modeling and programming layers simultaneously. At the modeling layer, domain concepts are represented as a Domain Specific Model (DSM), which is a set of UML diagrams. At the programming layer, domain concepts are represented as a Domain Specific Code (DSC), which consists of attribute-oriented programs. Attribute-oriented programming is a program marking technique. Programmers can mark program elements (e.g., classes and methods) to indicate they implement domain concepts. mTurnpike uses the annotations in J2SE 5.0 as the syntax of attributes. DSC is described as Java code decorated with the annotations. mTurnpike consists of the frontend and backend systems (Figure 1). The frontend system transforms domain concepts from the modeling layer to programming layer, and vise versa, by providing a seamless mapping between DSMs and DSCs. After DSC Generator generates a DSC (i.e., annotated code), programmers write method code in the generated DSC in order to implement dynamic behaviors for domain concepts∗ . The backend system of mTurnpike transforms a DSM and DSC into a more detailed model and program by applying a given transformation rule. mTurnpike allows developers to define arbitrary transformation rules, each of which specifies how to specialize a DSM and DSC to particular implementation/deployment technologies. For example, a transformation rule may specialize them to a database, while another may specialize them to a remoting system. The backend system consists of DSM Transformer, Skeleton Code Generator and DSC Transformer (Figure 1). DSM Transformer accepts a DSM, and specializes it to a particular implementation and deployment technologies. Given a transformation rule, it transforms (or unfolds) the DSM model elements associated with stereotypes and tagged-values into the plain UML model elements that do not have them. Skeleton Code Generator takes a plain UML model created by DSM Transformer, and generates skeleton Java code that corresponds to the input plain UML model. DSC Transformer accepts a DSC generated by DSC Gen∗ The methods in DSC are empty because DSMs and DSCs only specify the static structure of domain concepts.

erator, method code written on the generated DSC by programmers, and skeleton code generated by Skeleton Code Generator. Then, DSC Transformer combines them to generate the final compilable code (in Java).

timeout of message transmission (two minutes). mTurnpike implements a transformation rule between the SOA profile and Mule ESB† . synchrony = S ync timeout = 00:02:00.00

Application Developers

Abstraction Modelers Programmers Write method code level Describe models no DSM DSC ti re cra l DSC hg ts ev Generator iH bA eL DSL Transformer DSM Transformer

no it re cart l e w oL sbA veL

DSC Transformer Transformation rules

Plain UML Models

Visual Models

Skeleton Code Generator

encryptionA lgorithm = http://www.w3.org/2001/04/xmle nc#tripledes-cbc

《Service》 1

source

*

《MessageExchange》

dn et no rF

request

LoanApproval APR : float

algorithm =

algorithm =

http://www.w3.org/

http://www.w3.org/

2001/04/xmlenc# tripledes-cbc

2001/04/xmlenc#aes256-cbc

《Message》 RatingInquiry 《EncryptedProperty》 SSN: String

1

request

sink

《Service》

1

Bank

Textual Code

《Message》

LoanApp SSN: String

*

dn ek ca B

source

*

《Message》

Rating

《EncryptedProperty》

creditRating: int reply

《MessageExchange》

*

1

CreditRating

《Connector》

《Service》 CreditAgency

sink

RatingConn 《Logger》 : Logger

Figure 1. mTurnpike Architecture

3. A DSL for Secure Service-Oriented Network Applications In order to demonstrate how to exploit mTurnpike in application development, it has been used to develop distributed systems with a DSL for Service-Oriented Architecture (SOA) [6, 7]. The SOA DSL is defined as a UML profile. The proposed UML profile designs applications in an implementation independent manner using two major abstract concepts: services and connections between services. Each service encapsulates the function of a subsystem in an existing system. Each connection defines how services are connected with each other and how messages are exchanged through the connection. In addition them, the UML profile supports several security aspects in SOA applications: transport-level encryption, message-level encryption (entire/partial message encryption), message signature, message access control, and service access control. Figure 2 shows an example UML model (DSM) defined with the proposed UML profile. It illustrates a loan application processing in which a bank assesses whether to grant a loan to an applicant based on the applicant’s credit rating evaluated by a credit agency. Each service is defined as a class decorated with the stereotype ¿ServiceÀ. Services exchange four types of messages, each of which is stereotyped with ¿MessageÀ. The data fields steteotyped with ¿EncryptedPropertyÀ are encrypted with the algorithms specified as tagged-values (algorithm = ...). ¿ConnectorÀ represents a connection that transmits messages between services. Each connector can have multiple tagged-values to specify message transmission semantics. In this example, LoanAppConn specifies the synchrony of message transmission (synchronous) and the

reply

《Message》

LoanAppProcessing

Final (Compilable) Code

Representation

《Connector》 LoanAppConn

Applicant

synchrony = S ync timeout = 00:02:00.00

Figure 2. An Example DSM

4. Research Issues and Contributions This section summarizes how this project addresses several research issues. • A generic foundation to handle arbitrary DSLs. As described in Section 1, mTurnpike is expected to be generic to handle arbitrary DSLs, such as languages for application static architectures or security aspects, at both the modeling and programming layers. For this purpose, mTurnpike adopts a language-in-language design strategy in which different specialized languages are defined on top of a generic and customizable language. mTurnpike allows developers to define arbitrary DSLs and use arbitrary DSMs and DSCs. This design strategy contributes to improve the versatility of mTurnpike. In order to demonstrate how to exploit mTurnpike in application development, it has been used to develop distributed systems with a DSL for ServiceOriented Architecture [6]. • Building blocks for modeling and programming domain concepts. Traditional MDD tools accept domain-specific models in UML or other notations, and generate skeleton source code in general-purpose languages (e.g., Java, C++ and C#) [8,9]. In this scheme, although modelers work on modeling at a higher abstraction level, programmers have to work on generated code. The generated source code is often hard to read and understand. It tends to be complicated, time consuming †A

major open-source ESB implementation. http://mule.codehaus.org/

and error-prone to modify and extend. mTurnpike allows both modelers and programmers to work at a higher abstraction level (Figure 1). Programmers write method code in DSCs (i.e., annotated code) before generating skeleton source code. This means that programmers can focus on coding application’s business logic without handling the details in implementation and deployment technologies. • Development processes to leverage the proposed framework. mTurnpike maps domain concepts between the modeling and programming layers in a seamless and bi-directional manner. This mapping allows modelers and programmers to deal with the same set of domain concepts in different representations (i.e., UML models and annotated code), yet at the same level of abstraction. This means that modelers do not have to involve programming details, and programmers do not have to possess detailed domain knowledge and UML modeling expertise. This separation of concerns can reduce the complexity in application development, and increase the productivity for developers to model and program domain concepts.

• Transformation strategies domain-specific models to the final (compilable) source code. mTurnpike’s transformation mechanism currently supports static structure of a domain-specific model. Dynamic behavior is defined as method code in a DSC. mTrunpike copies method code from a DSC to the final code, and it does not transform the code. A future work will address a code transformation mechanism between a DSC and the final code. Also, to make the code transformation mechanism general (i.e., supporting arbitrary programming languages), a future work will investigate a general meta-model for programming languages (e.g., code transformation mechanism leveraging EBNF).

6. Concluding Remarks This paper overviews of the current status and future directions of the mTurnpike project. The author of the paper started his preliminary research project on 2004, enrolled in a Ph.D. course on September 2005, and will continue to carry out this Ph.D. project toward the graduation.

References

5. Future Directions • A generic foundation to handle arbitrary DSLs. mTurnpike currently supports only one DSL for each transformation from a DSM to compilable code. However, an application may require two or more DSL, i.e., DSLs for a vertical domain and a horizontal domain. A vertical domain means a business specific domain, such as banking and manufacturing. A horizontal domain means a technology specific domain, such as a middleware. Also, DLSs for non-functional aspects, for example, security, dependability and performance constraint, are required when developers specify non-funcitonal aspects explicitly. A future work will address generating compilable code through combining DSMs and DSCs written in multiple DSLs. • Strategies, principles and tradeoffs in different DSL designs. mTurnpike currently uses UML and UML profile to define a domain-specific model at the modeling layer. UML is a standard and powerful modeling language. However, it requires developers to understand its complex metamodel to define UML profile. Also, UML is tailored to objectoriented paradigm. Several MDD activities provide DSLs based on non-UML modeling languages tailored to particular domains (e.g., functional/non-functional requirements, data modeling and user interface). These languages are easier to customize than UML, but they are proprietary and raise a learning curve. Tradeoffs and selection criterions between them are not knows. A future work will address this research issue through developing generic foundation (e.g., using MOF, and supporting modeling notations other than UML such as Business Process Modeling Notation).

[1] G. Booch, A Brown, S Iyengar, J. Rumbaugh, and B. Selic. An MDA Manifesto. In The MDA journal: Model Driven Architecture Straight from the Masters, chapter 11. MeghanKiffer Press, December 2004. [2] G. Cook. Domain-Specific Modeling and Model-driven Architecture. In The MDA journal: Model Driven Architecture Straight from the Masters, chapter 5. Meghan-Kiffer Press, December 2004. [3] T. Lodderstedt, D. Basin, and J. Doser. SecureUML: A UML-Based Modeling Language for Model-Driven Security. ACM/IEEE Int’l Conference on Unified Modeling Language, October 2002. [4] J. J¨rjens. UMLsec: Extending UML for Secure Systems Development. ACM/IEEE Int’l Conference on Unified Modeling Language, October 2002. [5] M. Vokäc. Using a Domain-Specific Language and Custom Tools to Model a Multi-tier Service-Oriented Application– experiences and challenges. ACM/IEEE Int’l Conference on Model Driven Engineering Languages and Systems, October 2005. [6] H. Wada, J. Suzuki, K. Oba, S. Takada, and N. Doi. mTurnpike: a Model-driven Framework for Domain Specific Software Development. JSSST Computer Software. in press. [7] H. Wada, J. Suzuki, and K. Oba. A Service-Oriented Design Framework for Secure Network Applications. IEEE Int’l Conference on Computer Software and Applications Conference, September 2006. [8] O. Patrascoiu. Mapping EDOC to Web Services using YATL. Int’l Conference on Enterprise Distributed Object Computing, September 2004. [9] J. Greenfield, K. Short, S. Cook, S. Kent, and J. Crupi. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley, August 2004.