The Neocognitron was first proposed by Professor Kunihiko Fukushima in 1980. It is an artificial neural network based on the biological model of the human eye consisting of S (simple) and C (complex) cells. These cells work in a hirarchical fashion to selectively pick up distint patterns from an object until it is recognized. This neural network is used principally for pattern recognition.
In my thesis, in 1993, I implemented a, relatively simple, handwriting recognition application using the neocognitron. The implementation was done on the MasPar; a massively parallel computer using the SIMD (Single Instruction Multiple Data) paradigm. It worked surprisingly well and as a result I presented a paper at the Intelligent Information Systems conference in New Zealand in 1994.
Here's the abstract. (Sorry I don't have a full copy but it is available here: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=396925)
========================
Abstract
We consider the implementation of one of the most complex neural networks, the neocognitron, on a SIMD parallel machine. The neocognitron is a network with a heavy cell load and intricate interconnections among its neurons or cells. Its structure is qualitatively similar to the mammalian visual system and its algorithm exhibits data parallelism at several levels. The proposed implementation makes use of an optimal mapping strategy exploring this data parallelism and the communication network of the MasPar Mp12000 SIMD computer
========================
I'd like to now use this same technique for something more useful. What I have in mind is sign language recognition. The idea would be to have people write a letter or manage their computers using a simple web cam. I just thought this would be a cool project.
Tuesday, July 21, 2009
Converting a simple CXF application into a ServiceMix application
It is often a requirement to have to convert an existing CXF client/server-type application into a ServiceMix service unit (SU) JBI-type application. If you are an experienced developer with FUSE this is probably a trivial task. However, if you're just starting with the FUSE family of products converting a CXF application so that it is seen as a service in an ESB container could be daunting. For whatever reason you would need to do this here are some pointers to help you accomplish this task.
1. Decide whether you'd like the client(s), the server(s) or all the CXF entities (clients and servers) to be service units.
For the purpose of this article let's take the simple helloworld example available in the samples/wsdl_first directory of your FUSE-Services-Framework installation. This sample has a simple WSDL with some operations which are turned into a service upon which the client calls using SOAP/HTTP. So the testcase is composed of a server which hosts a service that contains a few operations and a client which uses SOAP/HTTP to make requests onto that server.
In a ServiceMix (ESB) environment one or all of those entities can be converted into service units which would then communicate using the JBI bus provided by the FUSE-ESB application. For the sake of this discussion I will turn the CXF server into a service unit and leave the CXF client as an external entity that will make requests through the ESB container to the service hosted within. In this situation the ESB container is actually hosting a service which can be reached by connecting to its endpoint (more about this later).
2. Based on your decision in 1. work out which servicemix component(s) you'll need.
Since the service will be hosted within the ESB container as a service unit we would need to make use of the servicemix-cxf-se component provided by the FUSE-ESB product (the "se" in servicemix-cxf-se stands for Service Engine). The component can itself be considered as a container hosting the service and providing endpoints with which other endpoints within the ESB container can communicate. The servicemix-cxf-se component is essentially providing an interface into the service(s) it is hosting. In this case servicemix-cxf-se will be providing the necessary endpoint for the CXF client to access the service in the ESB container.
To communicate with the client, which is outside the ESB container, another servicemix component is needed: servicemix-cxf-bc (where "bc" stands for Binding Component). The latter provides a way for application(s) running within the ESB container to communicate with the outside world.
3. Create a skeleton FUSE-ESB project for your application.
The easiest way to set up the required project skeleton for this application is to clone a similar example from the FUSE-ESB example list and then add and/or modify the necessary files in it to serve your purpose. An example that suits our particular needs for the purpose of this article is called cxf-wsdl-first and is found under the examples directory.
Make a copy of the cxf-wsdl-first directory and sub-directories and change the directory and file names appropriately. Here's an example of what our cloned skeleton project would look like:
Original cxf-wsdl-first example directory structure:
Where:
Bold - Directory name.
Italics - file name.
Skeleton Clone for our purpose:
As you can see the directory structure is basically the same with some directory name changes and all the files specifically pertaining to the example removed. This is the skeleton from which we'll start building our testcase.
4. Change the wsdl file and generate an implementation.
For the purpose of this article I will be using the hello_world.wsdl from the cxf-wsdl-first demo. We can obtain an implementation by generating the code using the wsdl2java utility from CXF. Since we will only be using the client on the CXF side and the service implementation within the ESB container we need to place the WSDL file in an empty directory, create another directory at this level called "src" and generate the required code using the following command:
The -ant option is used so that a build.xml will be created to facilitate the building and running of the client using the ant command.
After the code generator executes we are left with the following:
The implementation file should be among the generated Java files (GreeterImpl.java). This file should be moved to the cxf-smx-cxfse-su
service unit part of the FUSE ESB directory structure from step 3. In this case the implementation file name is GreeterImpl.java and the cxf-smx-cxfse-su directory looks like this:
(note: The directory com/progress/cxf_smx_soap_http comes from the namespace specified in the hello_world.wsdl file.)
The build.xml should be moved to the client level directory. Then the client is built and run using the following command:
where can be obtained from the build.xml under the element container the client class path in the description. In this case the is "GreeterClient".
5. Copy the WSDL file in the resource directories of the ServiceMix skeleton application.
Copy the helloworld.wsdl WSDL file to the resource directories of cxf-smx-cxfbc-su and cxf-smx-cxfse-su from step 3. This is the complete directory structure and files needed on the FUSE ESB side:
At this point the Servicemix application has all the files it needs in the right location. Now some files needs to be edited to accomodate for the names and file changes made so far.
6. Edit the pom.xml and xbean.xml files and make the required changes to allow building.
Before the Servicemix part of the application can be compiled the pom.xml files should be changed to reflect the changes in filename. This article is assuming that the reader is already familiar with maven and how to modify the "pom" file accordingly. However, the changes needed here mainly concerns name changes like the WSDL file name and the directory names that have changed as we went through all the above steps.
Similarly the xbean.xml files need to be edited to cater for the file name changes.
Once you're satisfied with all the editing you can build the application using:
from the main directory.
7. Deploy the service into the ESB container and run the client.
Once the servicemix part of the application is built successfully move the zip or jar file generated in the cxf-smx-sa/target directory to the hotdeploy directory and start the ESB container. The action of starting the ESB container will deploy your service. You can now run your client.
These are basically the main steps required to move an application from pure FUSE-Services-Framework (CXF) to FUSE-ESB (ServiceMix). There will be other requirements if you plan to use features like MTOM, WS-Addressing or if you wanted to specify an EIP (Enterprise Integration Patterns) using Camel. However, the main idea remains the same: build a template of what you want to achieve using an existing example (or build it from scratch using maven), move in the part(s) of the CXF application that need to be converted into Service Units to the ESB section, edit and change the necessary file(s) as appropriate.
1. Decide whether you'd like the client(s), the server(s) or all the CXF entities (clients and servers) to be service units.
For the purpose of this article let's take the simple helloworld example available in the samples/wsdl_first directory of your FUSE-Services-Framework installation. This sample has a simple WSDL with some operations which are turned into a service upon which the client calls using SOAP/HTTP. So the testcase is composed of a server which hosts a service that contains a few operations and a client which uses SOAP/HTTP to make requests onto that server.
In a ServiceMix (ESB) environment one or all of those entities can be converted into service units which would then communicate using the JBI bus provided by the FUSE-ESB application. For the sake of this discussion I will turn the CXF server into a service unit and leave the CXF client as an external entity that will make requests through the ESB container to the service hosted within. In this situation the ESB container is actually hosting a service which can be reached by connecting to its endpoint (more about this later).
2. Based on your decision in 1. work out which servicemix component(s) you'll need.
Since the service will be hosted within the ESB container as a service unit we would need to make use of the servicemix-cxf-se component provided by the FUSE-ESB product (the "se" in servicemix-cxf-se stands for Service Engine). The component can itself be considered as a container hosting the service and providing endpoints with which other endpoints within the ESB container can communicate. The servicemix-cxf-se component is essentially providing an interface into the service(s) it is hosting. In this case servicemix-cxf-se will be providing the necessary endpoint for the CXF client to access the service in the ESB container.
To communicate with the client, which is outside the ESB container, another servicemix component is needed: servicemix-cxf-bc (where "bc" stands for Binding Component). The latter provides a way for application(s) running within the ESB container to communicate with the outside world.
3. Create a skeleton FUSE-ESB project for your application.
The easiest way to set up the required project skeleton for this application is to clone a similar example from the FUSE-ESB example list and then add and/or modify the necessary files in it to serve your purpose. An example that suits our particular needs for the purpose of this article is called cxf-wsdl-first and is found under the examples directory.
Make a copy of the cxf-wsdl-first directory and sub-directories and change the directory and file names appropriately. Here's an example of what our cloned skeleton project would look like:
Original cxf-wsdl-first example directory structure:
|-- pom.xml
|
|-- wsdl-first-cxf-sa
| `-- pom.xml
|
|-- wsdl-first-cxfbc-su
| |-- pom.xml
| `-- src
| `-- main
| `-- resources
| |-- person.wsdl
| `-- xbean.xml
|
`-- wsdl-first-cxfse-su
|-- pom.xml
`-- src
`-- main
|-- java
| `-- org
| `-- apache
| `-- servicemix
| `-- samples
| `-- wsdl_first
| `-- PersonImpl.java
`-- resources
|-- person.wsdl
`-- xbean.xml
Where:
Bold - Directory name.
Italics - file name.
Skeleton Clone for our purpose:
|-- cxf-smx-cxfbc-su
| |-- pom.xml
| `-- src
| `-- main
| `-- resources
| `-- xbean.xml
|
|-- cxf-smx-cxfse-su
| |-- pom.xml
| `-- src
| `-- main
| |-- java
| `-- resources
| `-- xbean.xml
|
|-- cxf-smx-sa
| `-- pom.xml
`-- pom.xml
As you can see the directory structure is basically the same with some directory name changes and all the files specifically pertaining to the example removed. This is the skeleton from which we'll start building our testcase.
4. Change the wsdl file and generate an implementation.
For the purpose of this article I will be using the hello_world.wsdl from the cxf-wsdl-first demo. We can obtain an implementation by generating the code using the wsdl2java utility from CXF. Since we will only be using the client on the CXF side and the service implementation within the ESB container we need to place the WSDL file in an empty directory, create another directory at this level called "src" and generate the required code using the following command:
$ wsdl2java -d src/ -client -impl -ant hello_world.wsdl
The -ant option is used so that a build.xml will be created to facilitate the building and running of the client using the ant command.
After the code generator executes we are left with the following:
|-- build
|-- build.xml
|-- hello_world.wsdl
`-- src
`-- com
`-- progress
`-- cxf_smx_soap_http
|-- Greeter.java
|-- Greeter_SoapPort_Client.java
|-- GreeterImpl.java
|-- PingMeFault.java
|-- SOAPService.java
`-- types
|-- FaultDetail.java
|-- GreetMe.java
|-- GreetMeOneWay.java
|-- GreetMeResponse.java
|-- ObjectFactory.java
|-- PingMe.java
|-- PingMeResponse.java
|-- SayHi.java
|-- SayHiResponse.java
`-- package-info.java
The implementation file should be among the generated Java files (GreeterImpl.java). This file should be moved to the cxf-smx-cxfse-su
service unit part of the FUSE ESB directory structure from step 3. In this case the implementation file name is GreeterImpl.java and the cxf-smx-cxfse-su directory looks like this:
|-- cxf-smx-cxfse-su
| |-- pom.xml
| `-- src
| `-- main
| |-- java
| | `-- com
| | `-- progress
| | `-- cxf_smx_soap_http
| | `-- GreeterImpl.java
| `-- resources
| |-- hello_world.wsdl
| `-- xbean.xml
(note: The directory com/progress/cxf_smx_soap_http comes from the namespace specified in the hello_world.wsdl file.)
The build.xml should be moved to the client level directory. Then the client is built and run using the following command:
$ ant
where
5. Copy the WSDL file in the resource directories of the ServiceMix skeleton application.
Copy the helloworld.wsdl WSDL file to the resource directories of cxf-smx-cxfbc-su and cxf-smx-cxfse-su from step 3. This is the complete directory structure and files needed on the FUSE ESB side:
|-- cxf-smx-cxfbc-su
| |-- pom.xml
| `-- src
| `-- main
| `-- resources
| |-- hello_world.wsdl
| `-- xbean.xml
|
|-- cxf-smx-cxfse-su
| |-- pom.xml
| `-- src
| `-- main
| |-- java
| | `-- com
| | `-- progress
| | `-- cxf_smx_soap_http
| | `-- GreeterImpl.java
| `-- resources
| |-- hello_world.wsdl
| `-- xbean.xml
|
|-- cxf-smx-sa
| `-- pom.xml
`-- pom.xml
At this point the Servicemix application has all the files it needs in the right location. Now some files needs to be edited to accomodate for the names and file changes made so far.
6. Edit the pom.xml and xbean.xml files and make the required changes to allow building.
Before the Servicemix part of the application can be compiled the pom.xml files should be changed to reflect the changes in filename. This article is assuming that the reader is already familiar with maven and how to modify the "pom" file accordingly. However, the changes needed here mainly concerns name changes like the WSDL file name and the directory names that have changed as we went through all the above steps.
Similarly the xbean.xml files need to be edited to cater for the file name changes.
Once you're satisfied with all the editing you can build the application using:
$ mvn install
from the main directory.
7. Deploy the service into the ESB container and run the client.
Once the servicemix part of the application is built successfully move the zip or jar file generated in the cxf-smx-sa/target directory to the hotdeploy directory and start the ESB container. The action of starting the ESB container will deploy your service. You can now run your client.
These are basically the main steps required to move an application from pure FUSE-Services-Framework (CXF) to FUSE-ESB (ServiceMix). There will be other requirements if you plan to use features like MTOM, WS-Addressing or if you wanted to specify an EIP (Enterprise Integration Patterns) using Camel. However, the main idea remains the same: build a template of what you want to achieve using an existing example (or build it from scratch using maven), move in the part(s) of the CXF application that need to be converted into Service Units to the ESB section, edit and change the necessary file(s) as appropriate.
Subscribe to:
Comments (Atom)
