ESBConfig projects

This type of project is focused on web services and REST artifacts. We will create all the artifacts needed to develop the web services or REST services of our application inside this project.

To create a new project of this kind, we go to Developer Studio dashboard and click on ESB Config Project.

Then, we follow these steps:

1. Select New ESB Config Project and click on Next.
2. Type the name for the project and click on Next. We can keep the default values for the other options:

1. Finally, we introduce some Maven-required information for the pom.xml file that will be generated, that is, Group Id, Artifact Id, and Version. If needed, we can Specify Parent Project from the Workspace as well, and then click on Finish:

Now, we can see our new project in the Eclipse Project Explorer:

Now we are ready to add the artifacts that comprise our composite application to the project. The most common artifacts available are listed here:

• Proxy services: We use this artifact to create any kind of service different from REST services, for instance, Simple Object Access Protocol (SOAP) web services, VFS services, Java Message Service (JMS) services, and so on.
• REST API: With this artifact, we build REST services.
• Sequences: These artifacts allow us to structure service flow in little pieces so that the code will be more understandable, reusable, easy to read, and so on.
• Endpoints: These artifacts will be used to define communication endpoints the messages may be sent to, in other words, the destination we can send messages to.

However, how do all these artifacts work together to comprise our service?

Well, just take a look at the following diagram to clarify that:

1. The dotted arrow specifies the path followed by the incoming message, until it is sent to the final backend, in this case App1, and the black arrow indicates the response patch.
2. The Consumer sends a message to the service that can be implemented using a Proxy (SOAP Service) or a Rest API. In this element, we specify the interface configuring parameters such as Web Services Description Language (WSDL) or protocol.

1. From Proxy/Rest API, the message is sent to a sequence where we implement the service functionality. We can abstract our logic in several sequences that we can chain as desired. The incoming flow finishes sending the message through an endpoint to the backend, App1 in this case. We can set a specific sequence that processes the endpoint response; otherwise, a default sequence will be used.
2. The backend receives the message, processes it, and sends the response back to the out Sequence if using send mediator, or to the next mediator in the sequence if using call mediator. The endpoint will send the message to a sequence where the response can be processed or just sent back to the proxy.
3. Then, the outcoming flow finishes with the proxy replying to the consumer with the response.

Additionally, we need to define a sequence that will be executed when any error occurs during the process; this sequence is called Fault Sequence. The most common behavior of this sequence is to build an error message and respond to the consumer. This flow is reflected in the diagram with a striped arrow.

This is the best practice; however, you can omit creating a custom fault sequence, which means that the default fault sequence will be called in case of an error.

The flow described here matches a synchronous scenario where the consumer awaits the response. This may probably be the most common scenario; however, there are other scenarios as well:

• Asynchronous: The consumer does not remain blocked waiting for the response; the response may be received later
• Fire and forget: The consumer does not need a response

Once we know which artifacts we will need to build our service, we will learn how to create them with the IDE.