Refactoring your ACU COBOL and RM COBOL Applications with Xcentrisity BIS
•
0 gostou•1,226 visualizações
Learn how you can leverage your existing ACU and RM COBOL applications to take advantage of web technologies. Understand how to separate your UI from your business rules within your application. Position your COBOL applications to participate with other web based application environments. Harness the power of web services for your COBOL applications Today! ACU and RM COBOL users please Join us for this exciting discussion and demonstration using Xcentrisity BIS.
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (10)
Mais de Micro Focus
Mais de Micro Focus (20)
Refactoring your ACU COBOL and RM COBOL Applications with Xcentrisity BIS
- 1. Refactoring ACUCOBOL and RM/COBOL Applications with Xcentrisity® BIS Tom Morrison Sr. Manager Systems Software Projects
- 2. Overview • Refactor the GUI • Using web technologies • COBOL and SOA • Key benefits • Reorganizing an application for Web Services • Xcentrisity Business Information Server • XML Extensions • Transition to Visual COBOL • Demonstration 2
- 3. Using Web Technologies • Evolution, not revolution • COBOL as the programming language for web application engine • JavaScript Widgets – Example 1 – Example 2 • A look at the COBOL code • But we cannot build a real user interface on just widgets… 3
- 4. Delivering User Interface Artifacts • User interface is more than the GUI • How do you print reports on the Web? • But my customers want more than reports! Delivering spreadsheets, word processing documents and more • Data visualization and Dashboards • Examples 4
- 5. Web Services 5
- 6. Service Oriented Architecture (SOA) • A software organizing concept and methodology • “… a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.” 1 • The Problem: The Reality of Control • Concept: Service – Something (the „service‟) doing work for, or on behalf of, something else (the „client‟) – Implementation details unimportant to the cleint („loose coupling‟) • How can we take our legacy applications to SOA? • Can we do so on a budget, and quickly enough? 1. Reference Model for Service Oriented Architecture 1.0, OASIS, 2 August 2006. 6
- 7. COBOL before SOA • Modernization before „the web‟ and SOA – Modernize „the look‟ – Mitigate the closed nature of COBOL applications • Industry response was adding even more proprietary features to the language • Business rules still locked away 7
- 8. Reorganizing for Service Orientation • Loose coupling • Service contract • Autonomy • Abstraction • Reusability • Composability • Statelessness • Discoverability 8
- 9. Practical aspects of designing BREAD web services • REST versus SOAP • Remote Procedure Call (RPC) versus Document style • What does it mean to be stateless? – What record are we working with? – Record locking in a stateless world • Example 9
- 10. Gluing it all together • Widgets, applets, and web services: still not a GUI! • Adding a user-facing tier – ASP .NET – PHP – JSP • Desktop options: Visual Basic, C#, Java • How long will this user interface last? • Should we move the entire application to the browser? – User perception of „efficient‟ has changed – Watch Google, because they are training your users • „Customer written‟ using your new API • Web services inside frameworks; e.g. work flow engines 10
- 11. COBOL and SOA • „Bottom Up‟ approach to add Remote Procedure Call (RPC) style web services – Easiest to implement – Use legacy application code with modern, web service aware, user interface tooling • „Top Down‟ approach to add document style web services – Used at a higher level for coarser-grained business processes – Probably necessary to participate in a federation in an SOA environment • „Meet in the Middle‟ 11
- 12. Xcentrisity Business Information Server • This slide will emphasize the product features of BIS 12
- 13. XML Extensions • This slide will recap the use of XML Extensions within BIS • We will also touch on the use of XML Extensions for XML publishing. The tie in here is that reporting is part of the user interface, and that refactoring the GUI is only part of the requirement 13
- 14. Bibliography • Xcentrisity BIS Tutorial installs with BIS • A Collection of Xcentrisity Examples for XML Extensions and Business Information Server, Micro Focus • Service-Oriented Architecture, Thomas Erl • Table Trac bets on Micro Focus to modernize its application portfolio, Micro Focus customer success story • XSLT – Mastering XML Transformations, Doug Tidwell • www.w3schools.com tutorials 14
- 15. Demonstration • Show a simple RPC style web service implemented in BIS • Use soapUI to demonstrate the „raw XML interface‟ for the web service [oh…by the way, this is Java] • Use a browser to invoke pieces of the web service directly and others through PHP (a common server scripting language) • Show a Visual Basic or C# program using the web service 15
- 16. Questions 16
Notas do Editor
- Web technology creates a possibility to evolve your application’s user interface in response to your users’ needs. While we will describe here the possibility of a complete transition to a service oriented architecture, our customers have been very successful in using web technologies to deliver an upgraded user interface for a portion of an application, perhaps to use mobile devices or to provide public or more wide spread access to application functionality. Key to this possibility is the ability to have a web application engine that uses COBOL – your COBOL – as its programming language. If you have this capability, you don’t have to reengineer your data or your business rules to gain the advantage of web technologies.One can start, for example, by creating applets that feed JavaScript widgets. Let’s look at couple of these in action.[Example 1 is an autosuggest jquery widget.][Example 2 is a jquery grid.]Certainly these two user interface widgets would be immediately familiar to your application users. You’ll find similar widgets in just about any Rich Internet Application (RIA)Lets look at the programming behind these two widgets. Except for some boilerplate code that gets the information from the web request, and some other boilerplate code that gets the information back out to the requesting client, the COBOL code is quite familiar. We’ll explore this in a little more depth later.
- If you are contemplating using the web for your user interface, you will soon discover that someone changed the rules!While it seems that everyone has spent many hours considering how to get their application to a GUI, or to a better GUI, or at least to a modern GUI, the web has changed a lot more than that.For example, just how do you print reports at a user’s work station using the web? The good news is that everyone is self-trained if your application can produce and deliver PDF documents. And, using XML Extensions, for example, you can be creating PDF documents with just a few hours work.Business users demand more than reports in PDF documents. They want data in forms that are actually useful, and often this takes the form of spreadsheets or word processing documents. Again, using XML Extensions you can create Microsoft Office or OpenOffice documents. [Example dashboard with links to various artifacts.]
- But widgets and cute artifacts still don’t make a new user interface. At some point, you have to be able to get the data that runs your business on a screen in front of a user, and that user has to modify and manipulate the data in a meaningful way. In this case, ‘user’ may mean you traditional users of a desktop application, whether if be green screen or ‘legacy GUI’, or it may mean a whole set of new users, enabled by the use of web technology to use or at least better benefit from your application.Let’s consider what most business applications do. We look things up – these ‘things’ are chunks of data that mean something to a business. For the purpose of this talk, I am going to refer to these chunks of data as business objects. This is ‘objects’ in a very informal sense. Think in terms of ‘customer’, ‘invoice’, ‘purchase order’, ‘payment’, etc. If you catalog the screens of a typical business application, creating, modifying and deleting these so-called objects makes up a very large fraction of the total screens.Not surprisingly, this is not news. The software industry for years has talked about CRUD, which stands for Create, Read, Update, Delete, and has built fairly standard software design patterns that do CRUD for business objects.The paradigm of the web needs a bit more, because if there is one thing that characterizes a typical web-enabled business application, it is the ability to look thinks up, The acronym that combines CRUD with this new capability is BREAD: Browse Read Edit Add Delete.So, a reasonable design pattern would be to create a BREAD web service module for many, most or all of your application’s business objects. Remember again, though, that this is not an all-or-nothing conversion to web services, because your application continues to use the same data files and retains all of its previous functionality. You are merely adding new functionality.Before we look at how to build one of these BREAD web service modules, let look at some other characteristics of Service oriented Architecture, because we should understand the architectural principals of the web technology world, and work with those principals in mind.
- There has been a lot of hype associated with an approach to IT application design and construction known as Service-Oriented Architecture, or simply SOA. The seemingly universal application of this term to every vendor’s latest products, especially those that complement and used worldwide Web technology and infrastructure, serves only to confuse what is already a subject matter filled with buzzwords.Just to set the stage and, hopefully, separate this from some of the less content-rich marketing documents on this topic, let’s start by defining what we are talking about. {click}First of all, SOA is not really a prescription as much as it is an organizing concept. However, as we will see there is a methodology component as well, so that the vocabulary of has some practical meaning. {click}Let’s take a look at the definition provided by the Organization for the Advancement of Structured Information Systems – OASIS – First, it defines SOA as a “paradigm” or model, not an implementation or technique. This means that SOA guides the building of IT solutions, but it doesn’t itself solve any of the problems. Instead it encourages, if not dictates, the use of techniques and strategies that do indeed solve problems.Second, it declares that it offers guidance as to organization and utilization of disparate resources. These resources can be presumed to be any and all IT artifacts, from data files and databases to complete applications, and everything in between.Finally, and most importantly, it does not presume that all of the resources are “owned” by the same organization. This condition is crucial, for virtually all IT solutions built over the past 40 years have, in fact, made the assumption either explicitly or implicitly that all of the components of the solution are built and controlled by the same organization. So-called application-level integration technologies such as electronic data interchange (EDI) attempt to mitigate the consequences of this legacy design assumption, but only a fundamental architectural embracing of the concept of multiple domains of control can hope to produce a solution that can survive and thrive in the reality of today’s IT environment. SOA is the expression of that concept. {click}The problem that SOA attempts to solve is that of the reality of control. As programs comprise applications, applications comprise solutions, and solutions comprise IT systems, the odds of a modern IT system being composed of single-source components and data is nil. If we don’t expect this and design and build our applications to deal with it, we are doomed to be left behind by those who do. While it might seem like SOA is “just another way to build an application,” it is really the only way to build a modern application, particularly if the application is to have any chance at all of being useful for more than a few years. {click}Central to SOA is the concept of a “service.” A service implies that something is doing work for, or on the behalf of, something else. For this to take place, the work being offered must be useful to the client, the server must be willing to perform it, and the interface between the client and the service must be known to both. It is important to note that typically, it is neither necessary, nor even desirable, for the client to know how the service will be performed. This is the same “loose coupling” of components that has been at the heart of good single-source application programs for many years. It is axiomatic for any SOA design. When adhered to, it has been shown to be capable of producing extraordinarily powerful and flexible applications systems. This raises two vital questions. {click} How can organizations with huge investments in legacy applications migrate to an SOA-based architecture, and can they do so within practical budgets and quickly enough to be competitive?
- In the past, the choices for modernizing and re-hosting applications written in COBOL have been less than ideal. Before the advent of practical web technology, the modernization of COBOL focused on two main problems: how to make the application “look” better, and how to mitigate the notion that COBOL was a “closed system” for development. {click}The COBOL vendors responded to their customers’ pleas, and paid a lot of attention to the ‘look’ area. (This might not have been apparent to our customers!) As block mode terminals gave way to smarter character terminals, COBOL vendors responded with screen handling mechanisms of various sorts. Then, as the PC came into the market, we added more and more. The overall result was language bloat, a legacy of proprietary features that both COBOL vendors and customers struggle with. And even now, COBOL vendors cannot keep up with the Microsoft UI army, and the various open source brigades underwritten by Google, Adobe, and the like. Our applications still tend to look dated. {click}The main response to the closed nature of COBOL applications has been the widespread adoption of relational databases for the persistent data storage. But, with some rare exceptions, the business rules remain locked away in COBOL code. Some efforts have been made to allow cross-language calling and the like, but that really has hardly made a dent.
- Okay, so lets have a look at this new Service Oriented Architecture. There are eight principles of service orientation.Loose coupling: Services must be designed to interact without the need for tight, cross-service dependencies.Service contract: For services to interact, they need only share the formal contract that describes each service and defines the terms of use.Autonomy: The logic for a service is contained within an explicit boundary, within which it has control and is not dependent on other services for it to execute its governance.Abstraction: The only part of the service that is visible to the outside world is that which is in the service contract.Reusability: Services are designed to support potential reuse.Composability: Services may compose other services, allowing various levels of granularity and abstraction layers.Statelessness: Services should not manage state information, in part due to the fact that state information impedes loose coupling. Note that this might mean that state management might need to be placed elsewhere.Discoverability: Services shouuld allow their descriptions to be discovered and understood by humans and service requestors that may be able to use the services.The top four of these principles are considered core principles, while the other four support the realization of the core principles.
- There are some practical issues that the principles of Service Orientation impose on creating web services. And the fact that we are starting with legacy code will probably lead us in a particular direction.First, we need to know there are two types of web services ‘religion’, REST and SOAP. Both of these are perfectly good ways of implementing web services, and each has its own devotees. [Briefly describe the differences.] Then there is the issue of Remote Procedure Call versus document oriented web services. As COBOL programmers, we probably will feel more comfortable with RPC style webs services, since they fit comfortably into the ‘subroutine call’ paradigm. RPC serves well for short exchanges between a user-facing front end in a multi-tier web architecture, whereas document style web services are more useful in longer-running processes.
- We have created a new toolbox full of nice, shiny, new tools. And we still haven’t managed to get data in front of a user. The user interface has effectively been removed from the COBOL code, so what do we do now?The good news and the bad news is that you can now do just about anything. Remember that you need to make a decision!For a browser-based interface, you will have a user-facing tier on the web server. Options for this tier include Microsoft’s ASP .NET, PHP, or perhaps Java Server Pages (JSP), along with many others. These languages have the capability to consume web services, so they can use the web services you create for your business objects. You also have options for refactoring your desktop application, should that be desired. Visual Basic and C# .NET both can consume web services, naturally, and another strong contender would be Java. However, if refactoring a desktop application is your main goal, and you already have an ACUCOBOL GT user interface, you should consider a conversion to Visual COBOL using the tooling that will be described in this afternoon’s presentation.[TODO How long][TODO entire application?][TODO Customer written][TODO frameworks]