THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
ServiceMix JSR-
...
181
ServiceMix jsr181 JSR(181 component is a JBI Service Engine exposing (annotated) POJO as services on the JBI Bus.
It uses xfire internally to perform service invocations and xml marshaling.
...
- no annotations
- jsr181 annotations
- commons-attributes annotations
- aegis binding
- jaxb2 binding
- xmlbeans binding
- wsdl auto generation
Installation
Installing the servicemix-http component can be done in several ways:
- drop the installer zip in an hotdeploy directory monitored by ServiceMix
- using ant tasks
Note that when using ant tasks, the component is not started, you will have to start it manually using ant tasks or a console.
Configuration
Several parameters can be configured using a JMX console.
| Info | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
|
Deployment
You can deploy Service Units containing a file named xbean.xml for activating consumer and provider endpoints.
This xml file should respect the given syntax, though this is a spring based xml configuration file from where all beans of class Jsr181Endpoint are retrieved.
See a full example here. Note that you have to define the http namespace with
...
- MTOM / attachments support
Maven Archetype
You can create a JSR-181 Service Unit using the servicemix-jsr181-service-unit Maven archetype:
...
Once you've customized the service unit, simply install the SU:
...
Remember that to be deployable in ServiceMix, the ServiceUnit has to be embedded in a Service Assembly: only the Service Assembly zip file can be deployed in ServiceMix.
To add your SU in a SA, you need to define it in the dependency sets:
...
Endpoint Configuration
A JSR-181 endpoint only takes an annotated POJO in the pojoClass attribute:
...
A few other examples:
Any numbers of endpoints can be specified in the xbean.xml file.
As the main purpose is to expose a POJO, you will have to include the needed class files / jars in the service unit and reference them using the following tags in your xbean.xml configuration file:
| Code Block | ||
|---|---|---|
| ||
<classpath>
<location>.</location>
</classpath>
|
This will add the content of the location tags (relative to the unzipped service unit) to the classpath. The previous configuration will just add the class files contained in the service unit, as if it is a plain jar.
If you want to embed jars, just use something like
| Code Block | ||
|---|---|---|
| ||
<classpath>
<location>lib/foo.jar</location>
</classpath>
|
Endpoint
A few examples:
...
...
Name | Type | Description | Required |
|---|---|---|---|
annotations | String | The annotations used to configure the service. Can be "none", "java5", "jsr181", "commons". If not specified, the annotations type will be discovered by looking at the class. | no |
endpoint | String | JBI Endpoint name | no (will be auto-generated if not specified) |
interfaceName | QName | Interface QName implemented by the JBI endpoint | no (will be auto-generated if not specified) |
mtomEnabled | boolean | Enable MTOM / attachment support | no (defaults to false) |
pojo | Object | the instanciated POJO to service requests | one of pojo or pojoClass |
pojoClass | String | the class name of the POJO to service requests | one of pojo or pojoClass |
service | QName | JBI Service name | no (will be auto-generated if not specified) |
serviceInterface | String | the class name of the interface to expose as a service | no |
typeMapping | String | Can be "default", "xmlbeans", "jaxb2". Defaults to "default" (Aegis) if no annotations used, else defaults to "jaxb2" | no |
wsdlResource | if set, the wsdl will be retrieved from the given Spring resource | no | |
style | String | The SOAP style to use (document, wrapped, rpc) | no (defaults to "wrapped") |
validationEnabled | boolean | Specifies if the payload should automatically be validated. This feature only works for JAXB 2.0 payloads. | no |
...
Accessing the JBI bus
The prefered way to access the JBI bus is by retrieving a ComponentContext implementation.
The spring BeanFactory has a parent factory which contains a bean named "context" that you can refer to.
...
If you want to send a request to another service from your POJO, you can add the following method on your POJO:
...
You will be able to use the provided DeliveryChannel to send requests.
...
You can also use the client api:
...
...
Lightweight mode
The servicemix-jsr181 component can also be configured in a spring/xbean configuration file, for use in an embedded ServiceMix.
Here is an example of such a configuration:
| Wiki Markup |
|---|
{snippet:id=lightweight|lang=xml|url=http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-jsr181/src/test/resources/org/apache/servicemix/jsr181/spring.xml} |
...
| title | Classpath issues when embedding servicemix-jsr181 component |
|---|
...
...
Proxies
You can create java proxies for JBI endpoints, provided that they expose a WSDL.
...
The basic configuration is the following:
...
You can use it from one of you client bean, or from inside another component, and call the JBI endpoint as a plain Java object.
...
| lang | java |
|---|
From a jsr181 Service Unit, it could be used as following:
...
EJBs
Using spring EJB proxies, you can easily expose an existing EJB on the JBI bus.
...
...
MTOM support
MTOM is a way to handle large amounts of binary data in your services. Unlike attachments, the XML infoset stays the same. MTOM just "optimizes" any base64Binary data you have in your messages. When MTOM is turned on, this base64 data gets sent as a binary attachment saving time and space.
MTOM support can be turned on using:
...
MTOM is supported for the following classes:
- DataSource
- DataHandler
- byte[]
If you have a bean with the following method:
...
you will be able to call it using the following requests:
...
provided that the JBI message contains an attachment named "binary".
Accessing the JBI exchange
Some times, while processing the incoming request, you need to access the underlying JBI exchange.
It can be done using the following code snippet:
...