九乡新闻网英雄联盟熟练度:Mule3.0
来源：百度文库 编辑：九乡新闻网 时间：2024/04/28 14:30:38
Simple Book Order Processing Flow
Private Flow Example
This is an outbound synchronous endpoint3 which applies three message processors to the outgoing message: a global transformer, a wildcard filter, and a global custom processor. It then applies three more message processors to the response message: a locally-defined transformer, another wildcard filter, and a locally-defined custom processor.
Example #2
[Copy to clipboard]View Code XML
This is an outbound asynchronous endpoint3 which applies a whole chain of message processors to incoming messages. First a wire-tap router sends a copy of the original message to a monitoring queue after applying another global processor. Then a custom message splitter splits the message into parts, and the four remaining processors get applied to each new message from the splitter.
Backward Compatibility
For backwards-compatibility, we have left the endpoint attributes transformer-refs and responseTransformer-refs. Although use of these is deprecated for 3.0, if used, they will be applied after any other message processors. For example, the following Mule 2.2 configuration:
[Copy to clipboard]View Code XML
Simple Service ：
would be equivalent to the following Mule 3.0 configuration:
The first configuration pattern we’d like to present is called: Simple Service. Its goal is as simple as its name suggests: provide a simple way to expose request-response services. In other terms, it is used to expose some business logic in a synchronous manner over the transport of your choice.
address="vm://maths.in"
component-class="org.mule.tck.services.SimpleMathsComponent" />
Similarly, inbound endpoint and exception strategy can both be configured as child elements:
component-class="org.mule.tck.services.SimpleMathsComponent">
exchange-pattern="request-response" />
JAXB Support
Simple Service can handle JAXB serialized payloads. Nothing special is needed in the XML configuration:
address="vm://weather-consumer.in"
component-class="org.mule.test.integration.tck.WeatherReportConsumer" />
view rawgistfile1.xmlThis Gistbrought to you by GitHub.
But, for this to work, it is required that @Payload, a Mule-specific annotation, is used on the component:
packageorg.mule.test.integration.tck;
importorg.mule.api.annotations.param.Payload;
publicclassWeatherReportConsumer
{
public String consume(@Payload WeatherReportType weatherReport)
{
return weatherReport.report;
}
}
view rawgistfile1.javaThis Gistbrought to you by GitHub.
XPath Support
Finally, Simple Service can also handle XML payload with a direct extraction of values via XPath expressions. Like with JAXB, nothing special is needed in XML:
address="vm://weather-xpath-consumer.in"
component-class="org.mule.test.integration.tck.WeatherReportXpathConsumer" />
view rawgistfile1.xmlThis Gistbrought to you by GitHub.
But again, a Mule annotation, @XPath in this case, is needed for this to work:
packageorg.mule.test.integration.tck;
importorg.mule.api.annotations.expression.XPath;
publicclassWeatherReportXpathConsumer
{
public String consume(@XPath(value = "/weatherReport/report") String report)
{
return report;
}
}
view rawgistfile1.javaThis Gistbrought to you by GitHub.
Web Service Proxy
After the introduction ofSimple Service, the configuration patterns series continues!
The second pattern we would like to introduce is Web Service Proxy. Proxying web services is a very common practice used for different reasons like security or auditing. This pattern allows a short and easy configuration of such a proxy.
Core Features
A web service proxy acts as an intermediate between a caller application and the target web service. This gives the proxy a chance to transparently introduce new behaviors in the calling sequence. For example, it can:
· add or remove HTTP headers,
· transform the SOAP envelope (body or header) to add or remove specific entries,
· rewrite remote WSDLs so they appear to bind to services inside a corporate firewall,
· introduce custom error handling.
Let’s take a look at Web Service Proxy in action:
inboundAddress="http://localhost:8090/weather-forecast"
outboundAddress="http://ws.acme.com:6090/weather-forecast" />
WSDL Redirection
In some cases, the remote web service doesn’t follow the common practice of exposing its WSDL on the same address as the service with a “wsdl” appended at the end. In that case, it is required to point the Web Service Proxy to the exact location of the remote WSDL, as illustrated there:
inboundAddress="http://localhost:8090/weather-forecast"
outboundAddress="http://ws.acme.com:6090/weather-forecast"
wsdlLocation="http://ws.acme.com:6090/wsdl/weather-forecast" />
view rawgistfile1.xmlThis Gistbrought to you by GitHub.
In this scenario, the remote WSDL will have its port addresses rewritten as explained above.
For the case when no remote WSDL is available or if the remote WSDL needs manual adjustment before being exposed by the Web Service Proxy, the solution consists in storing the correct WSDL as a local file and have the proxy serve it. This is done as shown here:
inboundAddress="http://localhost:8090/weather-forecast"
outboundAddress="http://ws.acme.com:6090/weather-forecast"
wsdlFile="path/to/correct/weather-forecaster.wsdl" />
view rawgistfile1.xmlThis Gistbrought to you by GitHub.
In this case, the WSDL will be served as is from the file: no rewriting will occur.
Mule3.0的新特性
The Mule ESB team is pleased to announce the next milestone towards our final Mule 3.0 release. Recent work includes the following areas:
Hot Deployment – Mule now supports multiple applications running within the same Mule instance and deployment descriptors for specifying the contents of your deployment (e.g., multiple configuration files). Most of the Mule examples have been converted to the new deployment format*. If you have not yet read about the application deployment model new to Mule 3.0, read this blog post.
Message Exchange Patterns – Message Exchange Patterns (a.k.a. MEPs) give you more explicit and flexible control over the way messages flow through Mule. For example, you can now specify whether you expect a response on a given endpoint or not (see the new attribute “exchange-pattern” on endpoints). In the future, we may introduce additional exchange patterns that allow for different communication styles as well.
Message Processor API – An architectural change to simplify Mule’s internals and give it the flexibility to implement other patterns in the future which align more closely to specific scenarios beyond the service/component elements which you all know and love.
Flow Construct- A new XML tag that allows Mule configurations to take full advantage of the flexibility and power of the Message Processor API.
Message Property Scoping – Message properties are now scoped in either ‘inbound’, ‘invocation’ or ‘outbound’ scope. These scopes provide isolation and consistency to the way properties are attached to inbound and outbound messages.
Lifecycle Improvements – Improves behaviour during startup and shutdown of applications, a very important aspect of hot deployment. We have also added support for JSR-250 lifecycle annotations @PostConstruct and @PreDestroy.
Exception Strategy Improvements – Exception strategies were simplified to provide more consistent and predictable error-handling behavior.
CXF- CXF is now both more easily configurable and more flexible. CXF is now configured as a message processor within a flow. This message processor is simple to configure since there is specific XML syntax for each use case: client, server, and proxy.
Jersey- Jersey is now part of the base mule distribution with improvements. Like CXF, Jersey is now both easily to configure and highly flexible. Instead of being an endpoint type, Jersey is now implemented as a type of component that can contain any number of Jersey resources.
New and Different in Mule 3.0
Some of the major areas of improvements concern Mule Cloud Connect, simplified configuration, and an enhanced deployment model.
Mule Cloud Connect
Mule Cloud Connect is a collection of new features and improvements to Mule that make it dead-simple to securely integrate your enterprise with cloud-based data and services. At the core of it is iBeans - small, re-usable connectors that leverage the native web technology support in Mule to connect to external applications and data services.
Mule Cloud Connect includes:
Integration Beans - These are small re-usable cloud connectors that can be injected into your components to access external services such as Amazon Web Services, Twitter and Facebook. They provide a really easy way of accessing services managing all the security, request validation, data transformation and error handling.
REST / JAX-RS - Jersey is now part of the core mule distribution, providing native support for REST and JAX-RS. Like Apache CXF, Jersey is now both easily to configure and highly flexible. Instead of being an endpoint type, Jersey is now implemented as a type of component that can contain any number of Jersey resources.
AJAX - Mule now can integrate directly with JavaScript applications. Mule 3 includes server side endpoints and JavaScript client that allows events to be published directly to the browser and events to be published from the browser.
Web Services - Now more easily configurable and more flexible. CXF is now configured as a message processor within a flow or on an endpoint in a service. This message processor is simple to configure since there is specific XML syntax for each use case: client, server, and proxy. Axis is no longer included in the core Mule distribution but is still available for download from the MuleForge for use with legacy RPC-encoded web services.
ATOM and RSS - Mule 3 Now has built in support for polling feeds and splitting entries and producing ATOM feeds.
JSON Support - Mule 3 introduces JSON data handling. As well as adding JSON transformers, JSON data can automatically be marshaled into Java objects and back to JSON.
JAXB Support - Automatic XML binding now supported for components and new JAXB transformers have also been added.
Flow
Flow - A new way of configuring Mule to take full advantage of the flexibility and power of the new Message Processor API. Flow is a more natural way of defining some integration scenarios and more powerful and flexible than the Mule service model.
Patterns
Configuration Patterns - The introduction of configuration patterns in Mule greatly reduce configuration and make common tasks such as Transactional Bridging or creating a Web Service Proxy really easy.
Annotations
Annotations - New annotations have been introduced enabling injection of message information into transformers and components. The @Transformer annotation makes creating transformers much easier and the @Schedule annotation makes polling component methods simple.
Deployment
Deployment Model - Mule now defines a simple application model that allow individual services or groups of services to be deployed as packaged applications into the Mule run-time.
Hot Deployment - Mule now supports multiple applications running within the same Mule instance with complete isolation from other applications in the container. Development time automatic hot deployment is supported with new changes being affected within milliseconds.
Architecture Improvements
Message Processor API - An architectural change to simplify Mule's internals and give it the flexibility to implement other patterns in the future which align more closely to specific scenarios beyond the service/component elements which you all know and love.
Message Exchange Patterns - (a.k.a. MEPs) give you more explicit and flexible control over the way messages flow through Mule. For example, you can now specify whether you expect a response on a given endpoint or not (see the new attribute "exchange-pattern" on endpoints). In the future, we may introduce additional exchange patterns that allow for different communication styles as well.
Message Property Scoping - Message properties are now scoped in either 'inbound', 'invocation' or 'outbound' scope. These scopes provide isolation and consistency to the way properties are attached to inbound and outbound messages.
Lifecycle Improvements - Improves behaviour during startup and shutdown of applications, a very important aspect of hot deployment. We have also added support for JSR-250 lifecycle annotations @PostConstruct and @PreDestroy.
Exception Handling - Exception strategies were simplified to provide more consistent and predictable error-handling behavior.
Automatic Transformation - The transformation engine has been enhanced to support Data bindings such as XML/JAXB and JSON/Jackson. Also Mime types are now supported when discovering transformers.
CXF Now a Module - Mule 3.0 architectural changes bring much better support for CXF, meaning it can be used just like another pipe/filter element.
REST: First Class Citizen of Mule - Mule has enjoyed rich REST support since we released the REST Pack for Mule 2.0. The REST pack has been moved into the core, and we have added some new capabilities, such as support for including RSS and ATOM support and simplified configuration.
Examples
Changes to examples - The Loan Broker example has been simplified. The Mule Examples WebApp from Mule 2.x is temporarily removed for 3.0, but it will be restored soon. The examples no longer use the STDIO transport and instead use HTTP.
Other Changes
Message factories - Translate messages from the underlying transport format into a MuleMessage. Almost all messaging protocols have the notion of message payload and header properties. Message factories extract that payload and optionally copy all properties of the transport message into the MuleMessage. A MuleMessage created by a message factory can be queried for properties of the underlying transport message.
XQuery Support The XQuery Module gives users the ability to perform XQuery transformations on XML messages in Mule. This works in a very similar way to the [XSLT Transformer|MULE2USER:XSLT Transformer] shipped with Mule.
Dynamic Endpoints - Endpoints in Mule can now be dynamic. Addressing information can be constructed from the contents of the message or via any Mule expression.
JBoss jBPM - Mule has had integration with JBoss jBPM for a long time, but we have recently improved our support for Mule 3.0, including an upgrade to the latest major version of jBPM (4.4), much simplified configuration, and cleaner integration with Mule from your process definition, including custom process elements. For more information, refer to our BPM documentation.
Transaction Enhancements - By setting a new attribute on the element, Mule can now pay attention to (or ignore) transactions started outside of Mule.
XQuery Support - The XQuery Module gives users the ability to perform XQuery transformations on XML messages in Mule. This works in a very similar way to the XSLT Transformer shipped with Mule.
Schema Documentation - With Mule 3.0 comes a release of new Javadoc-style schema documentation, making it easier to familiarize yourself with all the elements and attributes permissible in xml configuration files.
AXIS Code Removed from MULE - An Axis support will be available as a separate EE module.
Private Flow Example
This is an outbound synchronous endpoint3 which applies three message processors to the outgoing message: a global transformer, a wildcard filter, and a global custom processor. It then applies three more message processors to the response message: a locally-defined transformer, another wildcard filter, and a locally-defined custom processor.
Example #2
[Copy to clipboard]View Code XML
This is an outbound asynchronous endpoint3 which applies a whole chain of message processors to incoming messages. First a wire-tap router sends a copy of the original message to a monitoring queue after applying another global processor. Then a custom message splitter splits the message into parts, and the four remaining processors get applied to each new message from the splitter.
Backward Compatibility
For backwards-compatibility, we have left the endpoint attributes transformer-refs and responseTransformer-refs. Although use of these is deprecated for 3.0, if used, they will be applied after any other message processors. For example, the following Mule 2.2 configuration:
[Copy to clipboard]View Code XML
Simple Service ：
would be equivalent to the following Mule 3.0 configuration:
The first configuration pattern we’d like to present is called: Simple Service. Its goal is as simple as its name suggests: provide a simple way to expose request-response services. In other terms, it is used to expose some business logic in a synchronous manner over the transport of your choice.
component-class="org.mule.tck.services.SimpleMathsComponent" />
Similarly, inbound endpoint and exception strategy can both be configured as child elements:
JAXB Support
Simple Service can handle JAXB serialized payloads. Nothing special is needed in the XML configuration:
component-class="org.mule.test.integration.tck.WeatherReportConsumer" />
view rawgistfile1.xmlThis Gistbrought to you by GitHub.
But, for this to work, it is required that @Payload, a Mule-specific annotation, is used on the component:
packageorg.mule.test.integration.tck;
importorg.mule.api.annotations.param.Payload;
publicclassWeatherReportConsumer
{
public String consume(@Payload WeatherReportType weatherReport)
{
return weatherReport.report;
}
}
view rawgistfile1.javaThis Gistbrought to you by GitHub.
XPath Support
Finally, Simple Service can also handle XML payload with a direct extraction of values via XPath expressions. Like with JAXB, nothing special is needed in XML:
component-class="org.mule.test.integration.tck.WeatherReportXpathConsumer" />
view rawgistfile1.xmlThis Gistbrought to you by GitHub.
But again, a Mule annotation, @XPath in this case, is needed for this to work:
packageorg.mule.test.integration.tck;
importorg.mule.api.annotations.expression.XPath;
publicclassWeatherReportXpathConsumer
{
public String consume(@XPath(value = "/weatherReport/report") String report)
{
return report;
}
}
view rawgistfile1.javaThis Gistbrought to you by GitHub.
Web Service Proxy
After the introduction ofSimple Service, the configuration patterns series continues!
The second pattern we would like to introduce is Web Service Proxy. Proxying web services is a very common practice used for different reasons like security or auditing. This pattern allows a short and easy configuration of such a proxy.
Core Features
A web service proxy acts as an intermediate between a caller application and the target web service. This gives the proxy a chance to transparently introduce new behaviors in the calling sequence. For example, it can:
· add or remove HTTP headers,
· transform the SOAP envelope (body or header) to add or remove specific entries,
· rewrite remote WSDLs so they appear to bind to services inside a corporate firewall,
· introduce custom error handling.
Let’s take a look at Web Service Proxy in action:
outboundAddress="http://ws.acme.com:6090/weather-forecast" />
WSDL Redirection
In some cases, the remote web service doesn’t follow the common practice of exposing its WSDL on the same address as the service with a “wsdl” appended at the end. In that case, it is required to point the Web Service Proxy to the exact location of the remote WSDL, as illustrated there:
outboundAddress="http://ws.acme.com:6090/weather-forecast"
wsdlLocation="http://ws.acme.com:6090/wsdl/weather-forecast" />
view rawgistfile1.xmlThis Gistbrought to you by GitHub.
In this scenario, the remote WSDL will have its port addresses rewritten as explained above.
For the case when no remote WSDL is available or if the remote WSDL needs manual adjustment before being exposed by the Web Service Proxy, the solution consists in storing the correct WSDL as a local file and have the proxy serve it. This is done as shown here:
outboundAddress="http://ws.acme.com:6090/weather-forecast"
wsdlFile="path/to/correct/weather-forecaster.wsdl" />
view rawgistfile1.xmlThis Gistbrought to you by GitHub.
In this case, the WSDL will be served as is from the file: no rewriting will occur.
Mule3.0的新特性
The Mule ESB team is pleased to announce the next milestone towards our final Mule 3.0 release. Recent work includes the following areas:
Hot Deployment – Mule now supports multiple applications running within the same Mule instance and deployment descriptors for specifying the contents of your deployment (e.g., multiple configuration files). Most of the Mule examples have been converted to the new deployment format*. If you have not yet read about the application deployment model new to Mule 3.0, read this blog post.
Message Exchange Patterns – Message Exchange Patterns (a.k.a. MEPs) give you more explicit and flexible control over the way messages flow through Mule. For example, you can now specify whether you expect a response on a given endpoint or not (see the new attribute “exchange-pattern” on endpoints). In the future, we may introduce additional exchange patterns that allow for different communication styles as well.
Message Processor API – An architectural change to simplify Mule’s internals and give it the flexibility to implement other patterns in the future which align more closely to specific scenarios beyond the service/component elements which you all know and love.
Flow Construct- A new
Message Property Scoping – Message properties are now scoped in either ‘inbound’, ‘invocation’ or ‘outbound’ scope. These scopes provide isolation and consistency to the way properties are attached to inbound and outbound messages.
Lifecycle Improvements – Improves behaviour during startup and shutdown of applications, a very important aspect of hot deployment. We have also added support for JSR-250 lifecycle annotations @PostConstruct and @PreDestroy.
Exception Strategy Improvements – Exception strategies were simplified to provide more consistent and predictable error-handling behavior.
CXF- CXF is now both more easily configurable and more flexible. CXF is now configured as a message processor within a flow. This message processor is simple to configure since there is specific XML syntax for each use case: client, server, and proxy.
Jersey- Jersey is now part of the base mule distribution with improvements. Like CXF, Jersey is now both easily to configure and highly flexible. Instead of being an endpoint type, Jersey is now implemented as a type of component that can contain any number of Jersey resources.
New and Different in Mule 3.0
Some of the major areas of improvements concern Mule Cloud Connect, simplified configuration, and an enhanced deployment model.
Mule Cloud Connect
Mule Cloud Connect is a collection of new features and improvements to Mule that make it dead-simple to securely integrate your enterprise with cloud-based data and services. At the core of it is iBeans - small, re-usable connectors that leverage the native web technology support in Mule to connect to external applications and data services.
Mule Cloud Connect includes:
Integration Beans - These are small re-usable cloud connectors that can be injected into your components to access external services such as Amazon Web Services, Twitter and Facebook. They provide a really easy way of accessing services managing all the security, request validation, data transformation and error handling.
REST / JAX-RS - Jersey is now part of the core mule distribution, providing native support for REST and JAX-RS. Like Apache CXF, Jersey is now both easily to configure and highly flexible. Instead of being an endpoint type, Jersey is now implemented as a type of component that can contain any number of Jersey resources.
AJAX - Mule now can integrate directly with JavaScript applications. Mule 3 includes server side endpoints and JavaScript client that allows events to be published directly to the browser and events to be published from the browser.
Web Services - Now more easily configurable and more flexible. CXF is now configured as a message processor within a flow or on an endpoint in a service. This message processor is simple to configure since there is specific XML syntax for each use case: client, server, and proxy. Axis is no longer included in the core Mule distribution but is still available for download from the MuleForge for use with legacy RPC-encoded web services.
ATOM and RSS - Mule 3 Now has built in support for polling feeds and splitting entries and producing ATOM feeds.
JSON Support - Mule 3 introduces JSON data handling. As well as adding JSON transformers, JSON data can automatically be marshaled into Java objects and back to JSON.
JAXB Support - Automatic XML binding now supported for components and new JAXB transformers have also been added.
Flow
Flow - A new way of configuring Mule to take full advantage of the flexibility and power of the new Message Processor API. Flow is a more natural way of defining some integration scenarios and more powerful and flexible than the Mule service model.
Patterns
Configuration Patterns - The introduction of configuration patterns in Mule greatly reduce configuration and make common tasks such as Transactional Bridging or creating a Web Service Proxy really easy.
Annotations
Annotations - New annotations have been introduced enabling injection of message information into transformers and components. The @Transformer annotation makes creating transformers much easier and the @Schedule annotation makes polling component methods simple.
Deployment
Deployment Model - Mule now defines a simple application model that allow individual services or groups of services to be deployed as packaged applications into the Mule run-time.
Hot Deployment - Mule now supports multiple applications running within the same Mule instance with complete isolation from other applications in the container. Development time automatic hot deployment is supported with new changes being affected within milliseconds.
Architecture Improvements
Message Processor API - An architectural change to simplify Mule's internals and give it the flexibility to implement other patterns in the future which align more closely to specific scenarios beyond the service/component elements which you all know and love.
Message Exchange Patterns - (a.k.a. MEPs) give you more explicit and flexible control over the way messages flow through Mule. For example, you can now specify whether you expect a response on a given endpoint or not (see the new attribute "exchange-pattern" on endpoints). In the future, we may introduce additional exchange patterns that allow for different communication styles as well.
Message Property Scoping - Message properties are now scoped in either 'inbound', 'invocation' or 'outbound' scope. These scopes provide isolation and consistency to the way properties are attached to inbound and outbound messages.
Lifecycle Improvements - Improves behaviour during startup and shutdown of applications, a very important aspect of hot deployment. We have also added support for JSR-250 lifecycle annotations @PostConstruct and @PreDestroy.
Exception Handling - Exception strategies were simplified to provide more consistent and predictable error-handling behavior.
Automatic Transformation - The transformation engine has been enhanced to support Data bindings such as XML/JAXB and JSON/Jackson. Also Mime types are now supported when discovering transformers.
CXF Now a Module - Mule 3.0 architectural changes bring much better support for CXF, meaning it can be used just like another pipe/filter element.
REST: First Class Citizen of Mule - Mule has enjoyed rich REST support since we released the REST Pack for Mule 2.0. The REST pack has been moved into the core, and we have added some new capabilities, such as support for including RSS and ATOM support and simplified configuration.
Examples
Changes to examples - The Loan Broker example has been simplified. The Mule Examples WebApp from Mule 2.x is temporarily removed for 3.0, but it will be restored soon. The examples no longer use the STDIO transport and instead use HTTP.
Other Changes
Message factories - Translate messages from the underlying transport format into a MuleMessage. Almost all messaging protocols have the notion of message payload and header properties. Message factories extract that payload and optionally copy all properties of the transport message into the MuleMessage. A MuleMessage created by a message factory can be queried for properties of the underlying transport message.
XQuery Support The XQuery Module gives users the ability to perform XQuery transformations on XML messages in Mule. This works in a very similar way to the [XSLT Transformer|MULE2USER:XSLT Transformer] shipped with Mule.
Dynamic Endpoints - Endpoints in Mule can now be dynamic. Addressing information can be constructed from the contents of the message or via any Mule expression.
JBoss jBPM - Mule has had integration with JBoss jBPM for a long time, but we have recently improved our support for Mule 3.0, including an upgrade to the latest major version of jBPM (4.4), much simplified configuration, and cleaner integration with Mule from your process definition, including custom process elements. For more information, refer to our BPM documentation.
Transaction Enhancements - By setting a new attribute on the
XQuery Support - The XQuery Module gives users the ability to perform XQuery transformations on XML messages in Mule. This works in a very similar way to the XSLT Transformer shipped with Mule.
Schema Documentation - With Mule 3.0 comes a release of new Javadoc-style schema documentation, making it easier to familiarize yourself with all the elements and attributes permissible in xml configuration files.
AXIS Code Removed from MULE - An Axis support will be available as a separate EE module.