Section 13.1. How are composite applications different from the previous generation of applications?
13.1. How are composite applications different from the previous generation of applications?To understand how composites are different, a high-level examination of traditional development practices will be useful. In the past, both in the mainframe era and in the client/server era, developers approached application development with a top-to-bottom perspective on the application stack. The same developer or team controlled the application being constructedfrom the user interface (UI) through the application logic down to the database. The developer, in essence, controlled a vertical slice of the application stack. Development generally proceeded by gathering requirements and then designing that vertical slice of the stack to create an application that met users' needs. If other parts of the existing code were needed, developers would check with the people who created those parts, often sitting down with them to understand how those parts worked and could be reused. Eventually, standard application programming interfaces (APIs) and frameworks such as CORBA and DCOM were created to promote reuse of certain types of functionality, but even then, knowledge of other developers was crucial to finding out how things really worked or how to perform certain tasks correctly. Also, almost all applications of the mainframe- and client/server-era applications were built on top of a single database. Development took place using various toolkits and application constructs designed to enhance the power of people writing code in third-generation computer languages such as ABAP, C, C++, and eventually, Java. This development paradigm created a huge amount of amazing software that led to the modern world of business applications, such as mySAP ERP and the mySAP Business Suite, as well as offerings from other vendors. Of course, as time passed, many different methodologies and divisions of labor were created to control development processes, but teams generally focused on the vertical slices of the stack. In the ESA world, developers and architects control horizontal slices of the stack. Coding in third-generation languages is replaced as much as possible by modeling. Enterprise services that were carefully constructed for reuse are the fundamental building blocks, not APIs or undocumented internal functionality. The database is no longer visible. Data used by a composite application is controlled by services. The division of labor has changed as well. Modeling makes development simpler and allows business analysts to create and configure certain types of composite applications. Developers or business analysts who create composites are in control of the UI, which can be modeled through SAP NetWeaver Visual Composer, and of the process logic, which can be modeled and implemented through guided procedures and other ways discussed throughout this book. The services layer is in the control of developers who are experts in third-generation languages. These developers, both those at software vendors and those in corporations, focus their time on creating services that can be provided to composite application developers. The data used by a composite may be located in several different service providers. In other parts of the book, we discuss helpful tools, such as the Enterprise Services Repository, that provide a comprehensive environment to search for services, understand their interfaces and how they work, and then use them from development tools such as SAP NetWeaver Visual Composer. Chapter 12 covers how development tools are used to create composites. The key question facing us now is how composite application developers deal with the fact that data is distributed in databases located in not one but several different service providers. 13.1.1. What are the challenges facing composite application developers and architects?Perhaps the most challenging difference between composite applications and those of previous generations is the way data is distributed throughout several service providers in most composite applications. Much of what we discuss in this chapter deals with how application developers have new responsibilities in this new world and how information management helps. Data is only the beginning of what composite application developers must face, however. They need to turn that data into information and then into knowledge. Other challenges include the fact that composite applications are being created in a world of demanding users who expect the highest levels of functionality, integration, and ease of use. In other words, composite applications must live up to higher expectations than previous generations. For example, analytics, collaborative functionality, and mobile versions of key applications are no longer an innovation but a must-have for many users. To better understand the challenges facing composite applications, let's imagine that we have gathered requirements from users and are ready to start exploring how we will create an application to meet their needs. The first stop may be the Enterprise Services Repository. By searching through the directory, developers identify the services that meet the needs of the application. Once they find a service, they can look at its interface and see how it fits into the process component models of the applications that use it. The models in the Enterprise Services Repository also may show the business objects that each enterprise service uses. OK, so now we have the services. What's next? The next question we may ask concerns the data. Where is the data that we need? How can we access it? Does the data exist in more than once place? What services can provide access to the data? (Perhaps these would have been the first group of questions many developers would have asked, but in a service-oriented world, we prefer to start with services.) In order to build applications in an ESA world, developers must have a catalog of data that maps where data is in all the service providers and helps to reconcile differences between them. It is also important that data inconsistencies be identified and cleaned (information quality) and that data can be moved around and synchronized easily when needed (information synchronization). What about a central repository of certain types of data consolidated from all of the different service providers? That certainly could come in handy. Somehow, composite application developers must be able to understand and manage the landscape of data. Once the data has been identified, it can be used to meet the needs of the application. One of those increasingly important needs is not only to create, read, update, and delete data, but also to provide tools to analyze the data in the context of a process and to take action with appropriate functionality. In other words, composite developers need tools for extracting meaningthat is, analytics in the broad sense, not just data analysis, and the means to do something about it. Analytic functionality can range from simple reporting to advanced interactive environments for advanced analysis using OLAP. The means to do something involves using the appropriate enterprise services. But doing something may mean working with others. Composite applications must not send users back to email when they need to get help from others, but instead should provide ways to engage others through collaborative functionality ranging from assigning tasks that can be managed to real-time, secure instant messaging to use of collaborative rooms or workspaces, blogs, Wikis, and bulletin boards. Collaboration often leads to communication that is captured in documents: what about documents, anyway? Composite applications must be able to incorporate unstructured documents into their functionality so that users are not sent to some other filesystem or search engine to find the documents related to the applications, which may exist in many different repositories. Documents related to the composite application should be managed within the composite. So should the ability to search for relevant documentsboth documents that reside within the composite and documents that reside outside of it. Given the distributed and real-time nature of most enterprises, mobile access has become vitally important not just for composites, but for all applications that are central to an organization's productivity. When called for, composites must be able to be used from mobile devices. While other challenges face composite application developers, if most applications had ways to address these challenges, the developers would be empowered and the applications would be powerful. 13.1.2. What is information management and how will it help?Information management is an umbrella term we are using for a group of capabilities focused on helping companies manage and extract the most possible value from the information assets that they create in the course of doing business. In providing these capabilities, information management solutions also can help meet the challenges facing composites that we just outlined. In our discussion of information management in this chapter, it is important not to lose sight of the fact that each solution we will discuss has a life of its own and solves many problems outside of serving the needs of composite applications. We added mobile access to this discussion because unified access to information from anywhere becomes increasingly important to support the knowledge worker efficiently. Our definition of the information management umbrella includes the following solutions:
These capabilities play an important role in helping developers create composite applications, but of course many other parts of ESA and SAP NetWeaver provide help as well. Project Mendocino helps extend composite applications into the Microsoft Office environment, and the services provided by the Enterprise Services Inventory provide more functional muscle. Global data types help keep data in a consistent format across many systems and services and given the central role that composite applications play, many more methods for accelerating their development will likely be created in the future. The rest of this chapter will explain the different parts of information management and SAP NetWeaver Mobile and will discuss how they help meet the challenges of composite application development. |
EAN: 2147483647
Pages: 265