Catálogo de publicaciones - libros

E nterprise Service Buses (ESBs) are all the rage in modern software development. You can’t pick up a trade magazine these days without some article on ESBs and how they make your life wonderful. If you’re a software development veteran, you’ll recognize the hype immediately. ESBs aren’t going to be the magic answer for our industry any more than were XML, web services, application servers, or even ASCII. Each of the aforementioned technologies started life with a lot of fanfare and unrealistic expectations (the result of the inevitable ignorance we all have with any emerging technology), and each technology ended up becoming a reliable tool to solve a specific set of problems.

T his chapter will walk you through the installation process for ALSB and the process of configuring your development environment. By the end of this chapter, you’ll be able to compile and run the sample code that comes with this book.

I n the tradition of computer learning books of the past several decades, in this chapter you’ll write a quick Hello World service to help you get an understanding of the basics of ALSB. During this process, you’ll gain a fundamental understanding of the ALSB interface, how to create a project using the ALSB console, and more. You’ll also see from end to end how to create and deploy business and proxy services on ALSB, along with how to create test clients to ensure that your services are working as desired. You’ll follow these steps: 1. Use Workshop to create and deploy a web service that implements the business logic.

M essaging is at the heart of ALSB. Messages are handled by message flows : a set of instructions on what to do with each message. In Chapter 3 you created your first message flow. It was trivial in nature, yet it shares the same basic set of components that even the most advanced message flows possess. Each message flow is constructed from one or more nodes. There are four basic node types: Start, Pipeline Pair, Route, and Branch. If no nodes are added to a message flow, then ALSB simply echoes the request message back to the caller.

I n this chapter, you’ll learn the “bare bones” of creating a WSDL by hand. Our goal in this chapter is to provide you with some best practices and quickly get you up to speed with the language. If you’re already comfortable with the WSDL language, you can safely skip this chapter. If you’re a WSDL/XML Schema purist, then reading this chapter will only upset you: we won’t take the time to cover the esoteric capabilities of the language here.

I n this chapter, you’ll do a couple fun and interesting projects to help you get accustomed to creating more advanced message flows. Before long, you’ll intuitively understand when to use each type of message flow node and exactly how get the maximum benefit.

M essages are at the heart of an ESB, and ALSB is no exception. Therefore, it’s worth your while to ensure you have a solid understanding of the principles of messages and invocation models. Much of this chapter is more specific to WLS than it is to ALSB. It’s important to know both sides of the “services equation,” and creating WebLogic web services will figure prominently in your ALSB work.

A lthough reporting and monitoring are discrete capabilities of the service bus, they’re closely related. Monitoring is the ability to collect runtime information, while reporting is focused on delivering message data and alerts. There’s also some overlap between monitoring and reporting. For example, you can monitor the number of alerts that have been reported. Monitoring is focused on operational information: the general health of the service bus, how many alerts have been generated and of what type, the status of Service Level Agreements (SLAs), and the gathering of related statistics. A simple way to differentiate between monitoring and reporting is this: monitoring is strategic, reporting is tactical.

U sing SOA-enabling applications and creating fine-grained services significantly increases the number of services for you to manage. Composite applications and services consume these additional services, which are distributed across the enterprise for orchestration or to provide high-level services or functionality to meet IT and business needs. The permissions to access to these services must conformto the security policies of the enterprise. If services are not secure, discerning legitimate requests from rogue access attempts is a daunting task. Unauthorized access to a service may result in degraded service performance or even in unavailability.

D esigning an enterprise SOA is a huge task. Although tools that help make creating and managing your SOA easier are advancing at a rapid pace, these tools cannot provide a substitute for the amount of human effort required to design the SOA itself. Many of the customers we meet are eager to start designing their SOA but almost immediately get “lost” in the details. Determining where to start can be a daunting task in itself.