WebSphere Integration Developer Guide Tutorial part 2nd

WebSphere Integration Developer Guided Tour part 2nd using WebSphere Integration Developer for SOA development

Build applications in a service-oriented manner

In part 1th of this series, we provide an overview of the product by introducing Ibm®websphere®integration Developer and the various tools it comes with. In the second article, you will learn about the programming model and the environment in which tools are used. To bring together the various aspects of this topic, we will describe a simple application and demonstrate how to build the application using the WebSphere integration Developer.

I'm sure you've heard of the term service-oriented architecture (SOA). But what are the SOA, and more important issues, and what are the benefits to the business integration area? We are very happy to answer your question. The WebSphere Integration Developer application is implemented through a service-oriented architecture, so we first discuss what SOA is and how it benefits our applications by following this architectural pattern.

Ideally, you want to be able to reuse an existing IT asset as a component or component to build a new application. Each artifact is a service, which means that you can access the service in a standard way without having to pay attention to its specific implementation and its location. In SOA, business logic is decoupled from the infrastructure, so developers can focus on implementation without having to focus on accessing the service.

In short, services are black boxes, and you are not concerned about their internal situation as long as they are able to work as stated. Once you have these black boxes, the next key step is to connect them together to form a complete application. These black boxes can be Java™ technology, business Process Execution Language (BPEL), connections to legacy systems, or adapters, and connections to WEB services provided by business partners. They are your service building blocks.

Services are usually stateless, which means that you don't have to worry about whether to call them in a particular order or in a specific context. Also, you may be planning to synthesize the services of your business partners and access them in a way that accesses your own services. You may also need a partner to access your service. With SOA, you can easily adapt to changing business environments by exchanging services or invoking new and required services. This makes business transactions between businesses easier.

What is the standard way to access a service? The service publishes its interface, which is also a contract between the service and the caller. Interfaces can be defined in a language, such as a Web service interface that can be defined through a Web Service definition language (Web Services definitions language,wsdl). An interface contains specifications for passing data to or from a service. Interfaces do not specify how services are implemented and what languages are used to implement them. Therefore, you might have a service that uses Java implementations that call another service that uses BPEL implementations.

All of this is a general overview that sounds good, but we need to delve into how to use the WebSphere integration Developer to implement a service-oriented architecture. In the previous article, we discussed various ways to implement a service, but did not give a detailed description of how the service works together. This article delves into the details of the service interaction.

Building Blocks for Applications

Building blocks are metaphors, which are very helpful in understanding the service-oriented architecture. Typically, you stack these building blocks together to build larger applications, which can be used as another building block. By analyzing the service in this way, you can easily master the Service component Architecture (Services Component ARCHITECTURE,SCA) programming model in WebSphere integration Developer. SCA is an implementation of SOA, and WebSphere integration Developer is a Workbench that, with the tools it provides, not only visually assemble the building blocks into a complete solution, but also build the inner work of each building block. The SCA standardization work is part of the Apache Tuscany Open source project. In the next few sections, you will learn the basics of using the Service component architecture for the basic layout of any solution that you want to build through the WebSphere integration Developer.

Module

A module is a container for a service that is both a project in the WebSphere integration Developer Workbench and a deployment unit on the WebSphere Process Server. This means that any solution you build will be deployed to the server as one or more modules. For developers who are familiar with Java EE, modules are packaged and deployed as Enterprise Archive (EAR) files. One of the advantages of a serviced component architecture is that you don't need to focus on the underlying packaging work. Modules provide services that can be used by other modules or by partners or customers through external clients. Modules are a collection of components, imports, and exports, which we will introduce in the following sections.

To create a module, right-click in the Business integration view and select New-module. The system will generate a new assembly diagram for the module you created, which you can edit using the assembly editor. The Business integration view is located on the left side of the assembly editor (if you do not move the view), showing all project artifacts. Figure 1 shows the newly created module.

Figure 1. New module