Migration to Service Oriented Architecture Using Web Services Whitepaper

Transcription

1 WHITE PAPER Migration to Service Oriented Architecture Using Web Services Whitepaper Copyright , HCL Technologies Limited All Rights Reserved. cross platform GUI for web services

2 Table of Contents 1. Requirement for a service-oriented architecture 3 2. What is SOA 3 3. Features of SOA 3 4. Advantages of SOA 4 5. The Role of Web Services in SOA 4 6. Why Use Web Services? 5 7. Where does Presenter5 Fit in? 5 8. The Advantages of Rich-Client Architecture 5 9. Some more Advantages of Presenter5 6

3 1. Requirement for a service-oriented architecture Leverage existing assets of middleware. Existing systems can rarely be thrown away, and often contain within them great value to the enterprise. Strategically, the objective is to build a new architecture that will yield all the value hoped for, but tactically, the existing systems must be integrated such that, over time, they can be componentized or replaced in manageable, incremental projects. Support rich client interface to be able to do away with the limitations due to thin client interface if at all. Allow for incremental implementations and migration of assets. Countless integration projects have failed due to their complexity, cost, and unworkable implementation schedules. Include a development environment that will be built around a standard component framework, promote better reuse of modules and systems, allow legacy assets to be migrated to the framework, and allow for the timely implementation of new technologies. 2. What Is SOA? Service-oriented architecture allows designing software systems that provide services to other applications through published and discoverable interfaces, and where the services can be invoked over a network. When you implement a service-oriented architecture using Web services technologies, you create a new way of building applications within a more powerful and flexible programming model. Development and ownership costs as well as implementation risks are reduced. SOA is both an architecture and a programming model, a way of thinking about building software. In an SOA: All functions are defined as services. This includes purely business functions, business transactions composed of lower-level functions, and system service functions. All services are independent. They operate as "black boxes"; external components neither know nor care how they perform their function, merely that they return the expected result. In the most general sense, the interfaces are invokable; that is, at an architectural level, it is irrelevant whether they are local (within the system) or remote (external to the immediate system), what interconnect scheme or protocol is used to effect the invocation, or what infrastructure components are required to make the connection. 3. Features of SOA SOA differs from other forms of computing in a few fundamental ways. Loosely Coupled: A software is organized into modular components. This is not a novel concept, but the difference with SOA is that the components, or services, are looselycoupled. Loose coupling is significant because it underlies the flexibility behind SOA. Loose coupling means services can be linked together dynamically at run-time, with few dependencies on how the services are actually implemented. Loosely-coupled services can be linked together easily and quickly as business requirements demand. Tightlycoupled systems are less flexible, usually involving recoding or recompilation when interdependent components are modified. Tight coupling makes it hard for applications to adapt to changing business requirements. 3

4 Interoperability: An important consequence of loose coupling is that services can run anywhere on the network and they are not restricted to a specific hardware or software platform or programming language. In a SOA, services can (and, in many cases, will) originate from different technology suppliers. Tightly coupled systems, on the other hand, usually involve a commitment to a specific software environment, which creates interoperability issues when different platforms need to be integrated. Standard Service Interface: The service interface describes how to call the service, specifying, amongst other things, where the service is located and the format of input/output parameters. The service interface is what provides another program with the information it needs to make a request to the service and get a response. The Customer Lookup service interface, for instance, might specify different ways of querying customer information (by customer id, by customer name, etc.), and the structure of the customer data that is returned by the service. The service implementation is the actual code that fulfills the functionality of the service. It is the logic that resides on a computer somewhere on the network and executes when called (subject, of course, to appropriate security constraints). Unlike the service interface, which is defined in a neutral format, the service implementation is inherently platformdependent. SOA is not concerned with how services are implemented architecturally-speaking it doesn t matter, for example, whether the Customer Lookup service is written in Java or COBOL only that a service fulfills the behavior specified by its interface. 4. Advantages of SOA SOA CHARACTERISTIC Loosely-coupled Modular approach Non-intrusive Standards-based General purpose technology BUSINESS BENEFITS Increases organizational agility; allows companies to easily assemble, and modify business processes in response to market requirements Provides a competitive advantage by offering greater flexibility in the way computer systems can be used to support the business Lowers implementation costs by increasing reusability; services can easily be shared across multiple applications Increases IT adaptability; changes resulting from mergers, acquisitions, package application implementations, etc. are integrated more easily Enables incremental development, deployment, and maintenance; avoids the need to do costly and risky big bang software implementations Decreases development effort by reducing complexity (through a divide and conquer approach) Over time, accelerates deployment of new application functionality; process becomes mostly assembly (of existing services) versus mostly new development Allows existing investment in IT assets to be leveraged Lowers risk and development effort; avoids the need to rewrite and test existing applications Platform independence allows companies to use the software and hardware of their choice Allows companies to engage in a multi-source strategy, reducing threat of vendor lock-in Reduces complexity and fragmentation resulting from use of proprietary technologies Lowers training requirements; increases available labor pool Delivers economies of scale; same technology can be applied to address a broad range of business problems 5. The Role of Web Services in SOA The ideas behind SOA modularization, platform independence, etc. are not new. Prior technologies have promoted many of the same principles, but failed to achieve the status of SOA. So why has SOA gained so much traction? The answer is Web services. On the one hand, Web services which are simply services that use specific XML-based protocols and interface descriptions to communicate provide the standards upon which today s SOAs are being built. Of these, the key standards are: SOAP (Simple Object Access Protocol), which deals with how an application calls a Web service to perform an operation and return an answer WSDL (Web services Description Language), which is the XML-based format used to define the 4

5 interface to a Web service UDDI (Universal Description, Discovery and Integration), a directory for Web services that lets applications find out what services are available to them Web services are accessible by applications through the Simple Object Access Protocol (SOAP), an XML form transmitted over HTTP. The advantage of using Web standards in an SOA is that the services can more easily adapt to different applications. Nothing in particular has to be done programmatically to the service, except to enable it to receive requests and transfer results using SOAP. So, in many cases, Web services are straightforward for an enterprise to build, and existing software can even be adapted to create new Web services. This concept of services is not new RMI, COM, and CORBA are all service-oriented technologies. However, applications based on these technologies require them to be written using that particular technology, often from a particular vendor. This requirement typically hinders widespread acceptance of an application on the Web. 6. Why Use Web Services? Major benefits of Web Services include: Interoperability among distributed applications that span diverse hardware and software platforms Easy, widespread access to applications through firewalls using Web protocols A cross-platform, cross-language data model (XML) that facilitates developing heterogeneous distributed applications Because you access Web Services using standard Web protocols such as XML and HTTP, the diverse and heterogeneous applications on the Web (which typically already understand XML and HTTP) can automatically access Web Services, and thus communicate with each other. These different systems can be SOAP ToolKit clients like presenter5, J2EE applications, legacy applications, and so on. They are written in C/C++, Java, Perl, and other programming languages. Application interoperability is the goal of Web Services and depends upon the service provider's adherence to published industry standards. 7. Where does Presenter5 Fit in? presenter5 (formerly Neuron Data s Open Interface Element) is the user interface development environment that is totally cross platform, integrates with web services and translates user interfaces into a dozen international languages. presenter5 provides 5 key features: Built-in, multi platform portability for faster, more economical development C/C++ for high performance of applications Support for web services ( XML) Power widgets for automatic GUI object generation Internationalization to support multiple languages and local requirements 8. The Advantages of Rich-Client Architecture In a rich-client system, part of the software runs natively on a client machine. In the often transactionintensive arena of business-critical applications this yields several advantages: Faster Performance, because the code runs natively on the client Rich Interface, since rich-client systems have access to the native windowing and GUI features of the operating system. Off-line Continuation of Work, since the relevant 5

6 code runs on the client and can take advantage of work-group and local databases. Immediate Feedback. Users get fast responses with context sensitive help, drop-down combo boxes, field-by-field validation, Tabbed forms, quick lookups for data searches, and automated process for data entry. Better Security, since it s possible to control just how much information is exchanged with third parties over the Internet. Better Reliability, because an application running on the desktop is more reliable and stable than one that may fail when the Internet connection is lost intermittently. It supports XP looks alongwith Windows3.1/95, X- motif, openlook and MAC Rich widget sets Several rich user widgets readily available in presenter5 which includes Browser, diagrammer, treeview, notebook, listbox, calendar and Web browser. No learning curve Quick development and provides rapid prototyping. HTML Browser Client consuming web services Firewal Application Servers T C P/I HTML Browser Client consuming web services Presenter5 based Rich Client Simply put, while the disadvantages of thin-client architecture have limited its usefulness as a foundation for business-critical applications, rich-client systems have proven resilient as the preferred choice in these areas. This is particularly the case for applications that require high levels of user interaction, reliability and security. Presenter5 based Rich Client Web Server supporting web Services using:.net / Java / gsoap 9. Some more Advantages of Presenter5 Easy migration of client No need to develop GUI from scratch as the current Presenter GUI could be re-used. Lower cost of development due to maximum reuse of existing components and less investment on development and re-testing Future safe technology presenter5 works with C/C++ libraries (ANSI standard) Presenter5 supports backward compatibility Native look and feel of OpenPDM client application presenter5 gives native look and feel to application. 6

7 Hello there. I am from HCL Technologies. We work behind the scenes, helping our customers to shift paradigms and start revolutions. We use digital engineering to build superhuman capabilities. We make sure that the rate of progress far exceeds the price. And right now, 45,000 of us bright sparks are busy developing solutions for 500 customers in 17 countries across the world. 7