Placement of SOA Applicance in Enterprise Architecture for Middleware Services

Transcription

1 International Journal of Information Science and Intelligent System, Vol. 2, No.3, 2013 Placement of SOA Applicance in Enterprise Architecture for Middleware Services Gautam K Bhat 1 1 IBM India, Chennai, India Abstract Received: 05 August 2013; Accepted: 11 September 2013 Service oriented Architecture is the heart of any Enterprise architecture. The present Infrastructure environments constitutes of Enterprise Service Bus comprising of hardware and software components interconnected by network devices. It is difficult for software based solutions running on standard servers and products to keep up with the complex integration of disparate platforms especially when the standards and specifications are in flux. An SOA appliance in such cases facilitates in several ways such as upgrading the firmware once with a quick restart of the appliance instead of performing repeated fix pack upgrades on the software, resolve issues related to operating system and hardware dependencies and like. Also in this dynamic business environment where the business needs changes with the blink of an eye with massive amount of data flowing in every micro second, it is even more essential to have high speed and acceleration incorporated into the Enterprise Architecture and this is possible using the appliance more than any other software. This paper covers its ideal applicability to less than full trusted networks in an enterprise architecture which is made possible through Tamper-proof casing, Default-off delivery from factory, Signed and encrypted file system, Optional Hardware Security Module (HSM), Certifications such as Common Criteria EAL 4 and FIPS Level 3. It also covers how Enterprise architecture could be built to accommodate services which are less sensitive and how they could be placed in DMZ and behind DMZ appropriately. When we talk about Enterprise architecture, monitoring becomes an essential part of it. This paper covers the SOA appliances ability to track messages as they flow throughout the enterprise, especially to determine where time and resources are being spent in complex scenarios involving several layers of enterprise systems such as application servers, databases and enterprise information system. Keywords: Business applications; Security; ESB; Middleware; Services; Datapower Martin Science Publishing. All Rights Reserved.

2 54 Gautam K Bhat / International Journal of Information Science and Intelligent System (2013) Introduction Organizations across globe of all sizes have expressed a growing need for migrating their existing application assets into new architectures guided by SOA concepts. The rationale is based on financial considerations, Employee skill migrations, Stability, Evolution in the form of emerging new technologies and innovative solution. SOA is an architectural style that supports service-orientation and enables a staged transition from a silo based system landscape towards an integrated, componentized, and shared service environment thereby enabling Legacy modernization [1]. The emergence and proliferation of the Extensible Markup Language (XML) and Web services has seen an explosion in the middleware infrastructure required to support them. An important component in this middleware architecture is in the enterprise service bus (ESB) which is a collection of runtime components that provides service intermediation such as routing, transformation, management, security, and other control functions. There are the three major problems at hand; which every enterprise architecture having Enterprise Service Bus solutions have to deal with. Foremost of all, the size and complexity of traditional software-based middleware product installations has increased installation and maintenance costs of service-oriented architecture (SOA) deployments and has thereby decreased overall solution consumability. Secondly on the performance aspect, the text-based, application parsing and processing demands placed on middleware infrastructures have negatively affected overall system performance. While virtualization has resulted in most middleware solutions "scale out", but the overall effect is increased license and operational costs as more instances of individual middleware components must be deployed to meet service consumer demand. Thirdly, the new genre of application-awareness has likewise led to a new genre of security attacks and exposures that use the architecture of middleware components. SOA appliances address these three challenges with the creation of specialized, purpose-built, consumable SOA appliances that redefine the boundaries of middleware. As the "hardware ESB," DataPower SOA appliances are an increasingly important part of the Enterprise Service Bus family [2]. The problem that we study herein is characterising the ability for SOA appliance to integrate with other components in an Enterprise Architecture. There is a limit up to which software components can plug in and integrate with several other services in an enterprise service bus solution. This paper provides ways to integrate the DataPower appliance with other products such as WebSphere Registry and Repository (WSRR), IBM Tivoli Composite Application Manager for SOA (ITCAM SOA) and Tivoli Composite Application Manager System Edition (ITCAM SE). In studying novel systems, Willsky asks [3], How can we extend existing services methodologies? How can we use existing methodologies in the context of a specific physical problem to obtain a tractable formulation which addresses the issues of interest in the more illdefined physical problem? The novel system here is that of adopting an appliance to solve known limitation or hindrance of service oriented architectural solutions. In the context of this

3 Gautam K Bhat / International Journal of Information Science and Intelligent System (2013) specific physical problem, the tractable existing framework within which we pursue our methodology is that of integrating SOA appliances into its discrete sub components. We seek to identify the system that transforms software into an hardware appliance at various times in the integration into the enterprise to solve consumability and productivity or revenue. Specifically, we use XI50, XI52, XB60 and XB62 devices, which leads to a stable and high performance solution that seamlessly fits into enterprise architecture. In production, the security, performance, and quality of service of deployed service oriented architecture solutions become extremely critical in maintaining continued business operations. In a high volume business transaction system, the performance of deployed services becomes even more critical. XML based SOA appliances are devised to address such high performance message processing requirements using SOA. Generally, such SOA appliances operate at the network layer in a DMZ zone and are built as hardware based network devices (with inbuilt software support) providing wire speed level message processing capabilities. Various types of hardware based SOA XML appliances are currently available in the market to address specific and special functionality of a SOA system. These SOA appliances provide specific functionalities in the areas of XML and SOAP security (Firewalls), XML accelerated processing (XML accelerators), high speed and high volume business integration through ESB, high speed B2B partner gateways, high throughput message processing and XML message caching for performance improvements. Such hardware based SOA appliances are fast becoming critical and essential parts of the enterprise SOA architectures. In this context, this paper discusses the main categories of SOA appliances currently available in the market and their role in enterprise SOA architectures [4]. The paper also discusses the product features of XML SOA appliances offered by key vendors in the market there by specifically focussing on a case study involving solution from Datapower XA35, XE40, XI50/52 for integration and routing and XB60/62 for B2B transaction processing. Here I have divided the paper into several smaller parts. We begin with the system model to give you a background of what is being done and a high level understanding of the need to go for SOA appliance. Followed by this we provide the architecturally viable components from SOA appliance perspective followed by integration set up and results section with details on every step performed and analyzed. Finally we have the discussion section ending with conclusion. 2. System Model In this section, we first describe the placement of WebSphere Datapower which is a hardware based solution through ESB appliance. Then we describe the system model of SOA appliance Datapower in SOA. 2.1 Applicability of websphere datapower appliance in variety of use cases Authors are encouraged to prepare figures, schemes and tables in color. Figure, schemes and tables must be numbered (Figure 1, Scheme I, Table 1, etc.) and an explanatory title must be added. All table columns should have an explanatory heading. Please supply legends for all figures, schemes and tables. Authors are encouraged to prepare figures, schemes and tables in color. Figure, schemes and tables must be numbered (Figure 1, Scheme I, Table 1, etc.) and an explanatory title must be added. All table columns should have an explanatory heading. Please supply legends for all figures, schemes and tables.

4 56 Gautam K Bhat / International Journal of Information Science and Intelligent System (2013) Figure 1. Network separation and placement of DataPower SOA appliance in the real time enterprise architecture. We chose DataPower for this architecture primarily because it provides varied appliances for transformation, routing and managing security aspects. For example, XA35 is a hardened appliance, but it has limited security processing functionality; it does not have the full XML threat protection or encryption/digital signature capabilities. For these reasons, it generally sits behind the DMZ shown as Trusted Domain in the above figure. The DataPower XS40 called the security appliance on the other hand sits in the DMZ as it has extensive security capabilities [4]. 2.2 Consideration for hardware based applicability of websphere datapower appliance in variety of use cases Secure Gateway This was adopted in the architecture at DMZ as it provides enhanced security features to the environment supporting - Terminate incoming connection, Terminate transport-level security, Enforce Service Level Agreement policies, Inspect message content, filter, pattern-match, Enforce security policies on message content, Call out to Access Control List(s), Detach binaries and call out to virus checker, Transform content (XSLT, XML-to-XML), Establish a new connection to pass results [5].

5 Gautam K Bhat / International Journal of Information Science and Intelligent System (2013) Figure 2. Positioning of B2B Gateway for security measures B2B Gateway This device also sits in DMZ as it provides good security control and serves the incoming client requests for AS1, AS2, AS3 protocols well [6]. This was chosen as the environment had several vendor s across globe who had agreed upon standards to share data using business protocols. An effective enterprise architecture is critical to business survival and success, and is the indispensable means to achieving competitive advantage through SOA. The Business to Business application has the additional burden of authenticating the incoming message data through any of the numerous means and pass through only the authorized message data to the backend system or third party vendor(s). 3. Deploying DataPower Appliance to Simplify the Enterprise Architecture While investigating the infrastructure it had several middleware components in haphazard manner totally disoriented as shown in figure 3 below.

6 58 Gautam K Bhat / International Journal of Information Science and Intelligent System (2013) Figure 3. Component placement within domains in an Enterprise Architecture The Enterprise Architecture laid foundation for all services and components but the manageability was a serious concern that imposed severe challenge and threatened terrible consequences. Any amount of software solution would have hampered and aggravated the existing problem at hand. The Datapower appliances were applied phase by phase adhering to the Architectural model there by simplifying the overall enterprise architecture as shown in figure 4 below, Figure 4. Component placement within domains in an enterprise architecture

7 Gautam K Bhat / International Journal of Information Science and Intelligent System (2013) SOA appliance usage in middleware services allows clear demarcation of application services and infrastructure support services. This is exceedingly important from scalability and security point of view. This also results in Application optimization and SOA optimization as such. The IBM solution of SOA appliance comes in two primary flavour in middleware services XI50 for transformation and routing and XB60 series for routing and orchestration. XB60 series appliance fits in well when a communication needs to go out of client network to outside world. 4. Empirical Forumla We collected data from one of the business units within a corporate organization and tested in a dedicate lab network. The final architecture comprising of middleware services was developed as shown below in figure 5. Figure 5. Sequence diagram comprising of Client system, Backend system and SOA appliance

8 60 Gautam K Bhat / International Journal of Information Science and Intelligent System (2013) (1)Perform Authentication based on the security token received in the security header of the request message in DMZ SOA appliance. (2) Request will be sent to Trusted SOA appliance from DMZ using https call [7]. (3) Perform schema validation against wsdl in the trusted SOA appliance. (4) Send the request to backend web service. (5) Validates the backend web service response and handle business and system exceptions. (6) Send the response back to the consumer. Figure 6. Architectural placement of SOA Appliance as a middleware service The final solution developed using middleware services [9] is as shown in Figure 6 above. The two SOA appliances fits in seamlessly in the overall solution thereby addressing and meeting the functional requirements and security aspects. In the above architecture, SOA Appliance is configured with the Registry service load balancer. Registry service load balancer internally distributes the workload to the two Registry and repository servers. In here the SOA appliance and Registry and repository subscriptions are synchronizing for every 24 hours.

9 Gautam K Bhat / International Journal of Information Science and Intelligent System (2013) Conclusion The SOA Appliance is a wide topic for discussion hence we have confined our discussion to a bare minimum covering the essential components that forms an enterprise architecture with respect to middleware services [8]. In this paper we have discussed at high level the different ways [9] of implementing SOA appliance in general with more emphasis on its actual implementation using DataPower appliance. We have intentionally kept product comparisons out of scope of this paper as such debatable discussions have been published elsewhere and also it does not serve the purpose of architecting an enterprise solution. Here we see that how the Datapower as a SOA appliance lowers the total cost of ownership by reducing the coding and development effort, eradicating operating system and file system for administrative purpose. We covered SOA appliance product family and ran through some use cases where the strengths of this platform are emphasized, and then took a closer look and discussed at a glance how the appliances fit in with the rest of the network infrastructure. We also adhered to SOA standards [10] while adopting DataPower appliance in the Enterprise Architecture as a Middleware service. Acknowledgments This work has been supported by Tamrat Tewoldeberhan from Lincolnshire, USA. I would also thank Rhonda Childress from IBM US for providing required support in developing this paper. References [1] Vedan Mehta, The Open Group Legacy Evolution to SOA Tutorial. [2] Juan R. Rodriguez, Somesh Adiraju, Joel Gauci, Markus Grohmann, Davin Holmes, Tamika Moody, Srinivasan Muralidharan, Christian Ramirez, IBM WebSphere DataPower SOA Appliances Part I: Overview and Getting Started. [3] A. S. Willsky, Some solutions, some problems, and some questions, IEEE Contol Syst. Mag., vol. 2, no. 3, pp. 4 16,1982. [4] MPhasis White Paper, SOA Appliances in Service Oriented Architectures. [5] OASIS Reference Model for Service-Oriented Architecture, Version 1.0, and OASIS Reference Architecture for Service-Oriented Architecture, Version 1.0, Organization for the Advancement of Structured Information Standards (OASIS); available from [6] OWL Web Ontology Language Reference, W3C Recommendation, World-Wide Web Consortium; available from [7] Service-Oriented Architecture Modeling Language (SoaML), Object Management Group; available from [8] The Open Group Service Integration Maturity Model (OSIMM) (C092), Technical Standard published by The Open Group, August 2009; refer to:

10 62 Gautam K Bhat / International Journal of Information Science and Intelligent System (2013) [9] A Competitive Review of SOA Appliances, Technology Analysis and Consultancy Group (2012). [10] SOA Reference Architecture Technical Standards from The Open Group (2012) under