1. What is Mulesoft? For what Mulesoft is used for? Answer: MuleSoft is the most widely used integration platform. Here we will find 2 types Mule ESB and Cloud Hub for connecting enterprise and SAAS applications in the on-premises and cloud. Mulesoft allows developers to connect applications together quickly and easily and it helps in exchanging the data. (mulesoft 4 interview questions)
2. Why Mule Was Designed? Answer: Mule’s core was designed as an event-driven framework combined with a unified representation of messages, expandable with pluggable modules. These modules would provide support for a wide range of transports or add extra features, such as distributed transactions, security, or management. The mule was also designed as a programmatic framework offering programmers the means to graft additional behavior such as specific message processing or custom data transformation.
3. What Is Service Layer In Mule? Answer: A Mule service is composed of all the Mule entities involved in processing particular requests in predefined manners. A service is defined by a specific configuration. This configuration determines the different elements, from the different layers of responsibility, that will be mobilized to process the requests that it will be open to receive. Depending on the type of input channel it uses, a service may or may not be publicly accessible outside of the ESB.
4. What are Shared Resources in Mule and how are they been used? Answer: We can make connectors as a reusable component by defining them as common resources and expose them to all applications deployed under the same domain, these resources are known as shared resources. These shared resource needs to be defined inside Mule Domain Project and then referred to each of the projects that are meant to use the elements in it. (online training institute)
5. What is Shared Context? Answer: Shared Context: Context is a temporary area which is created along with Service Message Object (SMO) in the Mediation Flows. Shared Context is a type of context which is present in the SMO. Shared Context is mainly used when we are using Aggregation process where we need to Iterate the BO for Certain times. Shared Context maintains Aggregation data between Aggregation (FanOut and FanIn) primitives. The Content (data) which is present in the shared context BO does not persist across Request and Response flows i.e The Data in the Shared Context which is used in Request flow can not be used again in Response flow.
6. What is the difference between Mule Connectors and Transports Mule ESB? Answer: Transports are targeted towards a way of transporting data, i.e. a protocol like HTTP or reading/writing files. These are general concepts and the other party behind such a data channel can be anything, a pure data sink or a party with whom data can be exchanged, own company or other. Connectors are made for using specific APIs, e.g. those from salesforce.com or facebook. Usually, choosing a connector also determines how the data will be transferred in the end, e.g. HTTP.
7. What is Shared Resource in Mule and how they have been used? Answer: We can make connectors as a reusable component by defining them as common resources and expose them to all applications deployed under the same domain, these resources are known as shared resources. These shared resource needs to be defined inside Mule Domain Project and then referred to each of the projects that are meant to use the elements in it.
8. What is the definition of Web Services? Answer: Web service is a function or program in any language that can be accessed over HTTP. Message format can be XML or JSON or any other program as long as the other programs can understand and communicate. Any web service has a server-client relationship. Web services can be synchronous or synchronous. Any web service can have multiple clients.
9. Why the Mulesoft is preferred than other ESB implementations? Answer: Mule is lightweight but highly scalable, allowing you to start small and connect more applications over time. The ESB manages all the interactions between applications and components transparently, regardless of whether they exist in the same virtual machine or over the Internet, and regardless of the underlying transport protocol used. Several commercial ESB implementation provides limited functionality or built on top of an existing application server or messaging server, locking you into that specific vendor. Mule is vendor-neutral, so different vendor implementations can plug into it. You are never locked in to a specific vendor when you use Mule.
10. How will we identify ESB is needed in a project? Answer: Implementation of ESB is not suitable for all the projects. We should analyze is really ESB is required here or not. You need to analyze by taking below points into consideration. In the project, require 3 or more applications and services to be integrated and there must be a need to communicate between the applications. If it is plain of interacting with more applications and Services in the future then we can go with Mule ESB because it is highly scalable. We need to keep cost also in mind before going to ESB implementation
11. What Difficulties Mule Does Encompass? Answer: Transport: applications can accept input from a variety of means, from the file system to the network. Data format: speaking the right protocol is only part of the solution, as applications can use almost any form of representation for the data they exchange. Invocation styles: synchronous, asynchronous, or batch call semantics entail very different integration strategies. Lifecycles: applications of different origins that serve varied purposes tend to have disparate development, maintenance, and operational lifecycles.
12. Why The Name Mule? Answer: There is a lot of infrastructure work to be done before we can really start thinking about implementing any logic. So this infrastructure work is regarded as “donkey work” as it needs doing for every project. A Mule is also commonly referred to as a carrier of load, moving it from one place to another. The load specializes in moving is our enterprise information.
13. What Are Differences Between Mule And Other Commercial Tabs? Answer: Prescriptive deployment model, whereas Mule supports a wide variety of deployment strategies. Prescriptive SOA methodology, whereas Mule can embrace the architectural style and SOA practices in place where it is deployed. Mainly focused on higher-level concerns, whereas Mule deals extensively with all the details of integration. Strict full-stack web service orientation, whereas Mule’s capacities as an integration framework open it to all sorts of other protocols. Comprehensive documentation, a subject on which MuleSource has made huge progress recently. ( python training online )
Answer: The first logical layer is the model layer. A Mule model represents the runtime environment that hosts services. It defines the behavior of Mule when processing requests handled by services. The model provides services with supporting features, such as exception strategies. It also provides services with default values that simplify their configuration.
15. What Is the Transformer In Mule? Answer: A transformer takes care of translating the content of a message from one form to another. It is possible to chain transformers to cumulate their effects. Transformers can kick in at different stages while a message transits through a service.
16. What Is Global Endpoint In Mule? Answer: An endpoint destination that is shared by several routers, it is worth creating a global endpoint. A global endpoint is not typified for inbound or outbound routing, making it usable in many different places in a configuration file. It must be named so it can actually be used in a service, which will reference the global endpoint by its name. A global endpoint can also help clarify the usage of a particular destination.
17. What Is Multicasting Router In Mule? Answer: The multicasting router can send messages to multiple endpoints over different transports. The multicasting router allows you to easily move the same messages across these different endpoints.
18. Why the Mulesoft is preferred than other ESB implementations? Answer: Mule is lightweight but highly scalable, allowing you to start small and connect more applications over time. The ESB manages all the interactions between applications and components transparently, regardless of whether they exist in the same virtual machine or over the Internet, and regardless of the underlying transport protocol used. Several commercial ESB implementation provides limited functionality or built on top of an existing application server or messaging server, locking you into that specific vendor. Mule is vendor-neutral, so different vendor implementations can plug into it. You are never locked in to a specific vendor when you use Mule.
19. What are the Message Sources in Mule ESB? Answer: Message sources in Mule are usually Anypoint Connectors, elements which provide connectivity to a specific external source, either via a standard protocol (such as HTTP, FTP, SMTP) or a third-party API (such as Salesforce.com, Twitter, or MongoDB).
20. What is Mule ESB? Answer: Mule ESB is a Java-based enterprise service bus (ESB) and integration platform, a developer can connect their application with ESB. Mule use service-oriented architecture. Apart from the different technologies the applications use, including JMS, Web Services, SMTP, HTTP. The advantage of ESB, it allows communicating different application. Messages can be any format SOAP to JSON. Mule ESB Development provides a messaging framework that enables the exchange of data among application.
21. What are the different types of Flow Processing Strategies? Answer: There are six different types of Flow Processing Strategies. They are Asynchronous Flow Processing Strategy. Custom Processing Strategy. Thread Per Processing Strategy. Queued Asynchronous Flow Processing Strategy. Synchronous Flow Processing Strategy. Non-blocking Flow Processing Strategy. Queued Flow Processing Strategy. Check Out Mule ESB Tutorials
22. What is the MuleSoft Anypoint platform and where it will be used? Answer: MuleSoft Anypoint Platform of integration products is designed to tie both software as a service (SaaS) and on-premises software.
23. Explain the difference between Callout and Service Invoke? Answer: Callout: We can call the service using callout or with service invoke. Use the Callout if we need to mediate a message (without calling an intermediate service) and then call a service provider. The Callout provides the simplest model for this configuration. Service Invoke: You need to interact with multiple services, and produce an output that combines service responses. The Service Invoke primitive does not switch from request flow to response flow. Use the Service invoke if we need to call an intermediate service. Example: We can use an intermediate service to adjust a message or to validate a message externally. The mediation flow contains Service Invoke mediation primitive, and a Callout node that is connected to the service provider there will be no intermediate service.
24. What Are Available Esbs Apart From Mule? Answer: All major JEE vendors (BEA, IBM, Oracle, Sun) have an ESB in their catalog. It is unremarkably based on their SVR technologies and is usually at the core of a much broader SOA product suite. There are also some commercial ESBs that have been built by vendors not in the field of JEE application servers, like the ones from Progress Software, IONA Technologies, and Software AG. ( devops training )
25. What Is Transport Layer In Mule? Answer: The transport layer is in charge of receiving or sending messages. This is why it is involved with both inbound and outbound communications. A transport manifests itself in the configuration by the following elements: connectors, endpoints, and transformers. A transport also defines one message adapter. A message adapter is responsible for extracting all the information available in a particular request (data, meta information, attachments, and so on) and storing them in transport-agnostic fashion in a Mule message.
26. What Is Payload In Mule? Answer: The content of a message, also known as the payload. It is wrapped in an instance of org.mule.api.Mule Message, which provides different means of accessing the payload under different forms. A MuleMessage also contains properties, much like the header of a SOAP envelope or the properties of a JMS message, and can also have multiple named attachments.
27. Is Mulesoft a middleware? Answer: Mule Enterprise Service Bus is a middleware technology that quickly, easily, and securely connects the enterprise. Unlike typical middleware software, Mule as an ESB is a Java-based middleware solution that is easy to use and easy to scale.
28. What is a Web service API? Answer: An API (Application Programming Interface) is the means by which third parties can write code that interfaces with other code. A Web Service is a type of API, one that almost always operates over HTTP (though some, like SOAP, can use alternate transports, like SMTP).
29. How can we create and consume SOAP service in Mule? Answer: Creating SOAP Service – We can create a SOAP service same as we create Mule Project With RAML, the only change is instead of RAML we need to import Concert WSDL. Consuming SOAP Service – We can use Web Service Consumer or CXF component in our mule flow to access/consume SOAP service.
30. What are all the Primitives used in Mediation? Answer:
We have different types of primitives in mediation. Message Filter:
- Type Filter
- Endpoint Lookup
- Service Invoke
- BO Map
- Message Element Setter
- DB lookup
- Data Handler
- Custom Mediation
- Header Setters
- Message Logger
- Even Emitter
- Sub Flow
31. What is Shared Context? Answer: Shared Context: Context is a temporary area which is created along with Service Message Object (SMO) in the Mediation Flows. Shared Context is a type of context which is present in the SMO. Shared Context is mainly used when we are using Aggregation process where we need to Iterate the BO for Certain times. Shared Context maintains Aggregation data between Aggregation (FanOut and FanIn) primitives. The Content (data) which is present in the shared context BO does not persist across Request and Response flows i.e. The Data in the Shared Context which is used in Request flow can not be used again in Response flow.
32. What is the functionality of Fan-in and Fan-out? Answer: Fan-out: We can use the Fan Out primitive to fire the output terminal once (with the input message) or fire the output terminal multiple times. You can use Fan Out in isolation or as part of a Fan-Out and Fan In combination.
33. What are the features of Mule ESB/ESB? Answer: Transport: applications can accept input from a variety of means, from the file system to the network. Data format: speaking the right protocol is only part of the solution, as applications can use almost any form of representation for the data they exchange. Invocation styles: synchronous, asynchronous, or batch call semantics entail very different integration strategies. Lifecycles: applications of different origins that serve varied purposes tend to have disparate development, maintenance, and operational lifecycles.
34. When Does Mule Instantiate A Connector?
Answer: If Mule figures out that one of our endpoints needs a particular connector, it will automatically instantiate one for us, using all the default values for its different configuration parameters. This is a perfectly viable approach if we are satisfied with the behavior of the connector when it uses its default configuration. This is often the case for the VM or HTTP transports.
35. Explain ESB Integration core principles? Answer: Transformation: Data transformation between canonical data formats and specific data formats required by each ESB connector. Transportation: Transport protocol negotiation between multiple formats. Such as HTTP, JMS, JDBC. Mediation: Providing multiple interfaces for the purpose of a) supporting multiple versions of a service for backward compatibility or alternatively, b) to allow for multiple channels to the same underlying component implementation. This second requirement may involve providing multiple interfaces to the same component, one legacy interface (flat file) and one standard compliant (SOAP/XML) interface. Non-functional consistency – For a typical ESB initiative, this can include consistency around the way security and monitoring policies are applied and implemented.
36. What is the use of Web service? Answer: Web services are XML-based information exchange systems that use the Internet for direct application-to-application interaction. These systems can include programs, objects, messages, or documents. A web service is a collection of open protocols and standards used for exchanging data between applications or systems.
37. How can you change the runtime changes using mediation primitive? Answer: We have future called Promotable properties in ESB training Bangalore. We can configure this future while development. Then we can make it changed at runtime without restarting the server it can be published.
38. What Are Configuration Builders In Mule? Answer: Mule uses configuration builders that can translate a human-authored configuration file into the complex graph of objects that constitutes a running node of this ESB. The main builders are of two kinds: a Spring-driven builder, which works with XML files, and a script builder, which can accept scripting language files.
39. What Is Streaming Property In File Connector In Mule? Answer: The value of this streaming property can be either true or false. If it is set to true then we are actually working on a stream of file data otherwise we are working with the file itself.
40. What are the various types of Exception Handling in Mule ESB? The types of exception handling in Mule ESB are:
- Default Exception Handling
- Global Exception Handling
- Catch Exception Handling
- Choice Exception Handling
41. What is the difference between ESB and JMS? Answer: ESB provides the middleware and interfaces that allow businesses to connect their applications without writing code. JMS provides messaging capability and facilitates communication between the modules/applications.
42. Explain about Fan-in and Fan-out? Answer: Fan-In: Fan-In is always in the flow with Fan-Out and helps in making a decision to continue flow execution. The Fan In may only be used in combination with Fan-Out. Fan-out: We can use the Fan Out-primitive to fire the output terminal once with the input message or to fire the output terminal multiple times. Fan-out can be used as a combination of Fan-Out and Fan In.
43. What Is Connector In Mule? Answer: A connector is in charge of controlling the usage of a particular protocol. It is configured with parameters that are specific to this protocol and holds any state that can be shared with the underlying entities in charge of the actual communications. For example, a JMS connector is configured with a Connection, which is shared by the different entities in charge of the actual communication.
44. What is caching and why to use it? Answer: Caching is a concept with is used to store frequently used data in the memory, file system or database which saves processing time and load if it would have to be accessed from original source location every time.
45. What is Transient Context? Answer: Transient Context: Used for passing values between Mediation primitives within the current flow — either the request flow or the responses flow. The transient context cannot link requests and responses and hence cannot be used across. Used when you want to save an input message before a service invokes call (within a request or response flow). After the services invoke call, the next primitive can create another message by combining the service invoke a response and the original message stored in the transient context.
46. What Is Component In Mule? Answer: Components are the centerpiece of Mule’s services. Each service is organized with a component at its core and inbound and outbound routers around it. Components are used to implement a specific behavior in service. This behavior can be as simple as logging messages or can go as far as invoking other services. Components can also have no behavior at all; in that case, they are pass-through and make the service act as a bridge between its inbound and outbound routers.
47. What is the MuleSoft Anypoint platform used for? Answer: MuleSoft’s Anypoint Platform of integration products is designed to tie together software as a service (SaaS) and on-premises software.
48. What are the advantages of Soap Web Services? Answer: AWS Security: SOAP defines its own security known as WS Security. Language and Platform independent: SOAP web services can be written in any programming language and executed in any platform. Disadvantages of Soap Web Services: Slow: SOAP uses XML format that must be parsed to be read. It defines many standards that must be followed while developing SOAP applications. So it is slow and consumes more bandwidth and resource. WSDL dependent: SOAP uses WSDL and doesn’t have any other mechanism to discover the service. ( tableau training online )
49. How Message In Mule Is Composed? Answer: A Mule message is composed of different parts: The payload, which is the main data content carried by the message. The properties, which contain the meta information much like the header of a SOAP envelope or the properties of a JMS message. Optionally, multiple named attachments, to support the notion of multipart messages. Optionally, an exception payload, which holds any error that occurred during the processing of the event.
50. How to find when the project needs ESB? Answer: ESB implementation is not suitable for all projects. Proper analysis should be done if the use of ESB will really benefit the project. Some of the points to be considered while analyzing the need of ESB are as follows: If the project requires integrating 3 or more applications/services. If the need is to communicate between two applications, using point-to-point integration would suffice. If the project would need to be scaled in the future where it might be needed to interact with more services in the future. Not all projects need this as they may perform not that big a task. If the project needs message routing capabilities such as forking and aggregating message flows. Such features are not required by all projects.(Mulesoft Training ) Is the architecture of what is to be achieved clear. It’s much better to do simple POCs integrating small parts to evaluate the benefits. Most ESBs are a costly affair. Does the project budget allow the use of ESB?