ACM SIGSOFT Software Engineering Notes
Page 1
September 2011 Volume 36 Number 5
Designing a SOA Based Model Ashish Seth
Himanshu Agarwal
Ashim Raj Singla
Institute of Technology and Science, Ghaziabad, India. +9109212651180
Punjabi University, Patiala, India. +919872654748
Indian Institute of Foreign Trade, Delhi, India. +9109350732238
[email protected]
[email protected]
[email protected]
ABSTRACT Service Oriented Architecture (SOA) is an architectural approach that can be shared and reused. Shortage of studies, research thrust and limited expertise in the area of SOA keeps the application of SOA in Small and Medium Enterprises (SMEs) limited. Also in a country like India, whose major economy is dependent on the small and medium enterprises, the Indian Government is promoting the growth in this sector. Successful examples of individual automated enterprise services and traditional ERP implementation systems exist but there is a lack of holistic, integrated technical solutions that can be applied in small and medium size enterprises. In this paper we propose a five layered SOA based architecture that can integrate all activities comprising Supply Chain Management (SCM), Customer Relationship Management (CRM), Technical and Enterprise Applications Tools according to SMEs requirement. We also compared our model with traditional ERP systems and other similar approaches and found the proposed model is efficient, cost effective and competent with similar existing solutions.
Categories and Subject Descriptors
Figure 1. Basic SOA Architecture The key functions, which the middleware must provide are publish, bind and find Publish (Service Registry/Discovery). An automated discovery of services must be provided as it is undesirable to manually provide each component with a priori knowledge of what other services are available on the enterprise network.
D.2.13 [Software Engineering]: Designing a service based dynamic model.
Bind (Service Access Control). This coordinates authentication, authorization and accounting functions.
General Terms
Find (Information exchange) The user can find among the various services published according to its need.
Management, Performance, Design, Standardization.
1.2 Service
Keywords Business Process, Architecture, SMEs.
Components,
Agility,
Services,
Layered
1. INTRODUCTION In today’s competitive scenario where business demand changes very frequently, the expectation from technology is raised to a level where we expect that the business processes are developed in such a manner that they can adapt the frequent changes without affecting the overall organizational business architecture. Thus the need of service oriented architecture arises for providing smart services which can be loosely coupled.
Service is an implementation of a well-defined business functionality that operates independent of the state of any other Service defined within the system. It has well- defined set of interfaces and operates through a pre-defined contract between the client of the Service and the Service itself, which must be dynamic, flexible for adding, removing or modifying services, according to business requirements. From a dynamic perspective, there are three fundamental concepts which are important to understand: the service must be visible to service providers and consumers, the clear interface for interaction between them is defined, and how the real world is affected from interaction between services. (See figure 2)
1.1 Service Oriented Architecture (SOA) SOA is a style of design that guides an organization during all aspect of creating and using business services (including conception, modeling, design, development, deployment, management, versioning, and retirement). Though SOA gives one the ability to easily integrate IT systems, provide multi-channel access to systems, automate business processes, which is also the need for current business; Moreover, SOA approach delivers a number of benefits including reduced time to market, improved business alignment for growth, reduced costs an d business risk. The core SOA lies on the concept of services but SOA architecture is not only about services; it is a relationship of three kinds of participants: the service provider, the service discovery agency, and the service requestor (user) (see figure 1)
DOI: 10.1145/2020976.2020993
Service Provider
Visibility
Service Consumer
Interaction Real World Effect SERVICE
Figure 2. Service Model
http://doi.acm.org/10.1145/2020976.2020993
ACM SIGSOFT Software Engineering Notes
Page 2
In general, entities (people and organizations) offer capabilities and act as service providers. Those who make use of these available services are referred to as service consumers (sometimes service consumers and services providers are jointly referred to as service participants) Service description allows prospective consumers to decide whether the services are suitable for their needs or not
Service Oriented Analysis
Service Oriented Design
September 2011 Volume 36 Number 5
1.2.1 Service Delivery Life Cycle (SDLC) SDLC in context of SOA starts with Service oriented analysis followed by Oriented Design, Service Development, Service Testing and finally Service Deployment. Throughout this process Service Administration is necessary to monitor the designed service and their orchestration for adhoc functionality (see figure 3). The task performed at each phase is as follows:
Service Development
Service Testing
Service Deploy ment
Service Administration
Figure 3. SOA Delivery Life Cycle • Service-oriented analysis, moreover, determines potential scope of SOA within the organization, Service are identified and mapped out from traditional legacy system to model as smart services.
BUSINESS NEEDS
BUSINESS IT Strategy
• In Service-oriented design phase, standards and protocols are designed conforming service level agreement (SLA), along with business processes.
• Service Deployment needs to configure distributed components, service interfaces, and any associated middleware products onto the production servers. • Services Administration is needed from service development phase onwards to keep monitor the designed services and their orchestration for adhoc functionality.
1.3 SMEs in India The SME segment has lately come into the limelight, with increased focus from several government institutions, corporate bodies and banks, and is viewed as agents of growth. Shortage of studies, research thrust and limited expertise in the area of SOA keep the application of SOA in SME limited. A country like India whose major economy is dependent on the small and medium enterprises is lacking behind due to unstructured information. Indian Government promotes the growth in this sector. It is estimated that SMEs account for almost 90% of industrial units in India and 40% of value addition in the manufacturing sector. The proposed study has been conducted to understand usage patterns and importance of alignment between IT and business processes in SMEs in India (see figure 4). To analyze the study 50 SMEs were interviewed in NCR Region including Delhi, Noida, Ghaziabad, Sahibabad, Gurgaon and Faridabad. It has been found that SMEs are bound with certain limitations, most important among which is low budget. Other limitation found by M. Sharma et.al (2010) are low capital base, inadequate exposure to international environment concentration of functions in one / two persons, inadequate contribution towards R & D. etc.
DOI: 10.1145/2020976.2020993
IT
ENTERPRI SE SOLUTION
IT CAPABILITIES
• Service Development phase is actual construction phase where services identified in design phases are coded using suitable language • Service Testing phase is required to undergo rigorous testing of services prior to deployment
ARCHITECTURE
Business Strategy
Figure 4 Business and IT collaboration
2.
RELATED WORK AND CONCEPTUAL FOUNDATION
Major modeling activities will concentrate on service discovery, service composition, (as described in basic SOA model) and service granularity, defining Service Level Agreements (SLAs). Zimmermann et al. (2004) specifies quality attributes for SOA that cover reusable (well-crafted services), loosely coupled, cohesive abstractions, stateless, meaningful to business and standardized to comply with enterprise architecture patterns and underlying technologies. According to Ravichandran et al. (2007) IT architectural design features for SOA must include reusable components, modular, autonomous, i.e. capable of interaction and adaptability without human intervention, interoperable, and reconfigured flexibly in run time through service matching and dynamic binding Indian SMEs are one of the most aggressive adopters of ERP Packages. In General, SMEs have limited funds and so their requirements are limited and have very small acute focus area. But, traditional ERP implementation products offer services that has larger focus area and always exceeds their specifications in every way (including costs).This gap between the SMEs requirements and traditional ERP’s specifications needs to be analyzed by the companies (traditional ERP providers) and the SMEs. Traditional ERP providers do not bring down their standards for the sake of the SMEs. Also it is not feasible for the latter to upgrade for the sake of the former. Compromise in either of the issues leads to direct monetary losses for either one party or both.
3. SOA LAYERED ARCHITECTURE The five layer SOA architecture (see figure 5) is used to design and implement the proposed model for current research work. The
http://doi.acm.org/10.1145/2020976.2020993
ACM SIGSOFT Software Engineering Notes
Page 3
explanation of the five layers SOA as used in organizations is as follows [4]:
Figure 5: Five layer SOA architecture •
Front End (FE) layer represent the front-end systems of the ICT environment. Each front-end system can access one or more services through a front-end adapter • Front End Adapter (FEA) layer represent the services which offer their services to the front-end systems. • Composite layer represent the services which combine the functionality of other services • Back End Adapter layer represent the services offered by the back end systems. A FEA service always invokes another service, either on the Composite layer or directly towards a Back End Adapter service. • Back End layer represent the back end systems of the ICT environment. Each back end system can be accessed by one or more services through a back end adapter
September 2011 Volume 36 Number 5
At the front end, there is a presentation layer which takes care of the front end user interaction. At the next, the business layer maps to composite layer in five layered architecture. This layer is sub layered to service layer and business model layer. The service layer comprise of all the services that are identified during analysis phase and are meaningful to the business. Business Model Layer defines the business processes and organizational business strategy. In Nutshell, Business layer performs the service orchestration task as per the business strategy. In layered architecture, the communication flows only within the two adjacent layers and no layer over cross the other layer. Thus, business layer is accessed only through presentation layer and the business model layer in turn accessible only through the service layer. The back end layer in the model reflects the data layer that directly interacts with the business layer at one end and database at the other (see figure 6). PUBLIC ACCESS LAYER
P
PRESENTATION LAYER INTERNAL ACCESS LAYER
SERVICE LAYER BUSINESS LAYER BUSINESS MODEL LAYER
DATA ACCESS DATA LAYER
In the proposed Approach the traditional systems are transformed to layered architecture as discussed above (see figure 7). Such reference model consists of minimal set of unifying concepts, axioms and relationships within a particular problem domain and is independent of specific standards, technologies, implementations, or other concrete details [OASIS-2006][5].
EXTERNAL DATA SOURCE LAYER
Figure 6. Mapping of five layers of SOA with the layers of Proposed Architecture
PUBLIC ACCESS LAYER PRESENTATION LAYER INTERNAL ACCESS LAYER (Secured with Firewall)
Can be implemented by using any of the web technologies like Struts, JSP, ASP.Net etc
SERVICE LAYER (Components COM/DCOM) BUSINESS LAYER Service Orchestration according to Business Strategy BUSINESS MODEL LAYER (Business Process / Strategy)
Implemented using J2EE beans, servelets. Components be designed using .Ne Framework
DATA ACCESS LAYER DATA LAYER EXTERNAL DATA SOURCE LAYER
Can be implemented by using Database like Oracle, Sql Server, DB2 etc
DATA BASE
Figure 7. Layered View of Proposed Architecture
DOI: 10.1145/2020976.2020993
http://doi.acm.org/10.1145/2020976.2020993
ACM SIGSOFT Software Engineering Notes
Page 4
4. SOA PROPOSED ARCHITECTURE The following architecture is proposed for the current research work (see figure 8). In the proposed architecture, the services corresponding to business objectives are identified and are placed in the repository using WSDL protocol. These services are orchestrated dynamically to define business process. The architecture itself is adhoc in nature and if at any time there is a change in business process, the service are intelligently orchestered dynamically to comply with new business process. In proposed architecture, on the left accesses the service registry to discover another service and interaction is done by sending a message, consider an example of placing an order. This message is often part of a longer conversation between the services. For example, an order followed by an acknowledgement, an invoice, payment notice, etc. For security some of these messages might be encrypted, or require authentication. In the figure the service provider is a composite service (composite service refer to service that uses other services to fulfill its responsibilities). For example, an order service might need to access inventory or pricing services in order to accept an order or issue a quote. The task of implementing such a composite service is frequently performed by an orchestration engine, an element optimized to execute a multi-step process, which include interaction with other services. A rules engine may be appended in the architecture to guide the orchestration engine in the execution of the process by incorporating
Discovery
September 2011 Volume 36 Number 5
business rules, such as order over a certain amount being handled with priority. The endpoint manages the translation between the asynchronous world of messaging and the synchronous application program. As separate applications and services use data in different format which may be incompatible, a translation of the message is often required along the way.
4.1 TESTING OF PROPOSED ARCHITECTURE The study adopted a descriptive type of research in which data was collected from various sources and analyzed to come to conclusion. Primary data was collected by visiting industry person, communicating face to face, conducting telephonic interviews and by mailing metrics designed through GQM. Secondary data was collected through magazines, internet, journals, and research articles on the subject. The following method is used for the testing of proposed model •
GQM (Goal / Question / Metrics ) Method is adopted to design questionnaire (evaluation metric ) on the basis of which effectiveness of the model is evaluated
•
Comparison Method – In this method the proposed model is compared with the existing similar approaches /technologies
•
Factor Rating Method is utilized to compare traditional ERP with certain identified factors.
Service Endpoints
Service Registry
Applications
SOAP SERVICE ORCHESTRATION
Service Composite
WSDL Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Business Values Chain Activities
ERP
SCM
CRM
Figure 8 – Proposed SOA Architecture
DOI: 10.1145/2020976.2020993
http://doi.acm.org/10.1145/2020976.2020993
ACM SIGSOFT Software Engineering Notes
Page 5
4.1.1 GQM (Goal / Question / Metrics) Method This method is adopted from Van Latum, et. al.(1998)[9] (see fig 8) The method works in three stages. At first stage organizational goals are identified in context of business strategies. In second stage questions are raised that comply with the goal identified in first stage. The answers to these questions help to understand the critical factors and risks that may be associated in achieving business objectives. In third stage, metrics are designed to evaluate the model.
Figure 8. Sample GQM Abstraction Sheet [10] In this study the last stage come up with the set of questionnaires which is capable to evaluate the proposed model. The designed metrics (questionnaire) is based on proposed model and then the responses are taken from 328-industry person. To evaluate it, average response is calculated and is found that the proposed architecture is very suitable for integrating business activities in SMEs. The Industry people are asked to answer on 5 point scale, where each point has following significance. (a) Weak support (1)
September 2011 Volume 36 Number 5
Sample questionnaire that is used to conclude the efficiency of proposed model (see table 1) Table 1. Sample Questionnaire
S No 1
With respect to definition, scope and functionality defined in terms of integration of business activities for proposed architecture Support pervasive standards for distributed computing interface descriptions and documents exchange via messages
2
Support extensibility for enterprise qualities of services such as security ,reliability and transactions
3
Support for composite applications such as business process flows , multi channel access , and rapid integration
4
Able to quickly modify business process as business requirements changes
5
Provide real time information and analysis on business processes for decision makers
6
Increased business agility
7
Better business alignment
8
Reduced integration cost
9
Can look up and use other services , including other composite services
10
Flexible and easily customizable so that it can be adapted to each project’s requirement
11
Insists on standard based integration techniques that are vendor neutral and technology neutral so that it can evolve as vendors and technology change
Points scored
4.1.2 Comparison Method This method evaluates the core technical efficiency of proposed model with other existing similar approaches. For comparison, the study has taken CORBA, XML web services and websphere. The table below shows the detailed comparative analysis of proposed model with different similar approaches (i.e. CORBA, XML web services, Web sphere MQ) architecture (see table 2).
(b) Minimum support (2)
4.1.3 Factor Rating Method
(c) Average support (3)
In this method certain factors of adoption are identified on the basis of which decision has to be made, whether the proposed model is efficient in comparison to traditional ERP or not. The factors were compared and are analyzed on a scale of 3 in terms of difficulties that may face with the proposed model and traditional ERP systems
(d) Good support (4) (e) Strong support (5) The sample questionnaire is prepared based on proposed model and then the response is taken from 328-industry person to evaluate it. The average response is calculated and is found that the proposed architecture is very suitable for the integrating business activities in SMEs.
DOI: 10.1145/2020976.2020993
• value 1 represents Low difficulty • value 2 represents Moderate difficulty • value 3 represents High difficulty
http://doi.acm.org/10.1145/2020976.2020993
ACM SIGSOFT Software Engineering Notes
Page 6
September 2011 Volume 36 Number 5
Table 2. Comparison of proposed SOA architecture with different similar approaches S.No
Elements of service platform
Proposed Model
CORBA
XML‐web services
Websphree MQ with custom extensions
1
Open standards
Yes
Yes‐OMG
Standards in place but fragmented across multiple organization.
No‐ propriety
2
Loosely coupled
Yes
Mediocre
Yes
Yes
3
Support for multiple programming languages
Yes
Yes
Yes
Mediocre
4
Technology service definition
High platform independency
CORBA‐ IDL
WSDSL and XML schema Adhoc‐ text file, word, Proposed standards – WS‐ excel, access Policy Schema
5
Interface repository
UDDI
CORBA interface repository
6
Data Privacy / integrity
Through rule engine embedded in service orchestration
7
Publish‐ subscribe
Yes‐ strong support
8
Load balancing
9
Transaction management
neutral contract
–
UDDI based
None
IIOP/TLS
HTTP/S, WS‐ security
None
Yes
Multiple proposed standards
Yes‐ weak support
Within the architecture
Yes
Not addressed by standards
Yes
Through composite
OTS (including XA support
Support for two phase commit and compensating transaction
Websphere MQ’s as XA‐ compliant transaction manager
service
Table3. Factors of Adoption The following table (see table 3) demonstrates the different factors of adoption with their score and weighted score Based on the factors and their weighted score, their graphical analysis has been done and is shown below (see figure 10). The graph clearly shows Traditional ERP systems have high weighted scores compared to proposed model. It has been observed during the survey that in ERP systems every factor except security has high score (only two factors ie integration and resource competence have equal score) The summation weighted scores of all factors in case of traditional ERP comes is 241.5 which is very much higher than summed weighted score of the proposed model. This analysis clearly shows that the model is readily adaptable and much efficient than traditional ERP approach.
Factors
Score
Weighted Score
ERP
Proposed Model
Weights
Security Agility
1 3
2 1
Availability
2
ROI
2
Integration Performance
1 2
ERP
Proposed Model
7.0 6.5
7.0 19.5
14.0 6.5
1
6.5
13.0
6.5
1
6.0
12.0
6.0
1 2
6.0 6.0
6.0 12.0
6.0 12.0
Adaptability
2
2
5.5
11.0
11.0
Scalability Maintainability
3 3
1 2
5.5 5.5
16.5 16.5
5.5 11.0
20
Migration
3
2
5.0
15.0
10.0
15
Mobility Up gradation
3 3
2 1
5.0 5.0
15.0 15.0
10.0 5.0
Traditinal ERP
Flexibility
3
1
5.0
15.0
5.0
Proposed Model
Implementation
Installation
3 3
2 1
4.5 4.5
13.5 13.5
9.0 4.5
Transparency
2
1
4.5
9.0
4.5
Deployment Accessibility
3 2
2 1
4.0 4.0
12.0 8.0
8.0 4.0
Resource Competence
1
1
4.0
4.0
4.0
Total
45
27
100
241.5
142.5
10 5 0
1
4
7
10 13 16 19
Figure 10. Graphical analysis of traditional ERP Systems and proposed system on identified factors (the number at horizontal axis correspond s to the factors shown on above table)
DOI: 10.1145/2020976.2020993
http://doi.acm.org/10.1145/2020976.2020993
ACM SIGSOFT Software Engineering Notes
Page 7
5. RESULTS Following result are obtained after applying all the three approaches for testing the model. Comparison Method: This method evaluates the core technical efficiency of proposed model with other existing similar approaches. After comparing the specifications of proposed model with CORBA, XML web services, it is found that proposed model is equally competent with other existing technologies and has strong support of adaptability and agility. GQM Method - The designed metrics (questionnaire) is prepared based on the proposed model using GQM approach and then the response is collected from 328-industry person to evaluate it. On the basis of calculated average response, it is found that the proposed architecture is suitable for integrating business activities in SMEs. Factor Rating Method - The analysis on identified factors clearly shows that model is readily adaptable and is much efficient than traditional ERP approach. It is readily deduced that Traditional ERP systems involve higher levels of difficulty when analyzed in terms of agility, adaptability and availability.
6. CONCLUSION The architecture is a logical construct that cares very little where or on what platform a service provider runs. It is designed in such a way that it provides single service connectivity and a management tier that reduces the development time and cost and at the same time meets the changing requirements. New services and clients will be added throughout the lifetime of the application. The proposed architecture is capable to deploy at all kinds of SMEs, as it is a generalized model. For the present work 50 SME located in NCR region are targeted to collect data and evaluate the efficiency of proposed model. The work will further be realized by examining the state-of-the-art in relevant frameworks and technologies for its development and deployment. Finally, Introduction of a distinct integration tier shows the ability to add in value added services which provide packaged solutions for common developmental needs.
September 2011 Volume 36 Number 5
[2] Ashish Seth, Kirti Seth, A.R. Singla. 2010. Aspect of Service Oriented Computing. JCT Journal of computing. http://www.iste.org/learn/publications/journals/jct-abstracts.aspx [3] Craig M. Parker,Tanya Castleman. 2007. New directions for research on SME-eBusiness: insights from an analysis of journal articles from 2003 to 2006”, Journal of Information Systems and Small Business, vol. 1, no. 1-2, pp. 21-40. [4] Jianqiang Hu, FengE Luo, Jun Li, Xin Tong, Guiping Liao, 2008. SOA-based Enterprise Service Bus. Proceedings of the 2008 International Symposium on Electronic Commerce and Security – ISECS, Pg 536-539. [5] OASIS. 2006. Reference Model for Service Oriented Architecture 1.0 [6] Forman, G. 2003. An extensive empirical study of feature selection metrics for text classification. J. Mach. Learn. Res. 3 (Mar. 2003), 1289-1305. [7] Brown, L. D., Hua, H., and Gao, C. 2003. A widget framework for augmented interaction in SCAPE. In Proceedings of the 16th Annual ACM Symposium on User Interface Software and Technology (Vancouver, Canada, November 02 - 05, 2003). UIST '03. ACM, New York, NY, 1-10. http://doi.acm.org/10.1145/964696.964697. [8] Yu, Y. T. and Lau, M. F. 2006. A comparison of MC/DC, MUMCUT and several other coverage criteria for logical decisions. J. Syst. Softw. 79, 5 (May. 2006), 577-590. http://dx.doi.org/10.1016/j.jss.2005.05.030. [9] Spector, A. Z. 1989. Achieving application requirements. In Distributed Systems, S. Mullender, Ed. ACM Press Frontier Series. ACM, New York, NY, 19-33. http://doi.acm.org/10.1145/90417.90738 [10] Van Latum, F. 1998. Adopting GQM based measurement in an industrial environment”. IEEE Software 15(1), pp 78–86 [11] Winter, R., Fischer, R. Essential Layers. 2006. Artifacts and Dependencies of Enterprise Architecture. EDOC Workshop on Trends in Enterprise Architecture Research (TEAR 2006). IEEE Computer Society, Los Alamitos
7. REFERENCES [1] Alcedo Coenen. 2006. SOA Case Study: Agility in Practice. Open Group SOA Case Study. http://www.opengroup.org
DOI: 10.1145/2020976.2020993
http://doi.acm.org/10.1145/2020976.2020993
