Sometimes when you create a Service Unit for the [JavaEE Service Engine|http://wiki.open-esb.java.net/Wiki.jsp?page=JavaEESE](e.g., an EJB service) you end up with an extra SOAP Binding Component Service Unit which is deployed whether you want it or not. This article explains why that happens and how you can remove / disable it.
{toc}
h2. Why it is created
The JavaEE Service Engine in OpenESB and JavaCAPS is a little different from other [JBI|http://wiki.open-esb.java.net/Wiki.jsp?page=LearnJBI]Service Engines.
Most Service Engines are containers which both execute their Service Units and provide the JBI-compliant APIs and functionality to allow those Service Units to operate in a JBI-compliant environment. For instance the [BPEL Service Engine|http://wiki.open-esb.java.net/Wiki.jsp?page=BPELSE] executes one or more bpel processes, each of which are individual Service Units. The BPEL SE implements the necessary functionality to allow those Service Units to:
* be deployed and managed based on the JBI lifecycle
* to turn interactions to and from those service units into JBI compliant Message Exchanges based on Normalised Messages
* implement Quality of Service features such as transactionality, security, etc.
all without the developer having to worry about implementing these things in the bpel process itself.
In contrast the JavaEE SE acts as a bridge between the JBI Container and service consumers and providers executing in other JavaEE containers - the EJB Container and the Web Container. It still provides the necessary JBI-compliant APIs but the "Service Units" are actually regular EJBs and webapps running in the AppServer.
!javaeesu3.JPG!
The way this works in OpenESB/JavaCAPS, is that you develop regular JavaEE components which are webservice consumers and providers. If you deploy these as part of a JBI Service Assembly (a Netbeans Composite Application project) then references are created the JavaEE SE and all communication to and from these "services" are intercepted and passed from the NMR, through the JavaEE SE to the webapp or EJB, rather than going over the wire. For instance, you can create a JavaEE Service Unit by building a regular [JAX-WS compliant webservice|http://www.netbeans.org/kb/60/websvc/jax-ws.html] and including it in a Composite Application project.
This is described in more detail in the following references:
* [JBI and Java EE - Implement SOA with Java EE & JBI | https://open-esb.dev.java.net/public/whitepapers/ImplementingSOA.pdf]
* [Bridge the gap between Java EE & JBI | http://weblogs.java.net/blog/binod/archive/2006/07/java_ee_service_1.html]\\
One consequence of this approach is that the JavaEE Service Unit (the JAX-WS EJB) will have its own webservice endpoint when deployed in the AppServer, plus, the endpoint it provides through the JavaEE Service Engine to other services running in the JBI container. If you only want to communicate to/from other services in the JBI container then you get an extra soap binding which,
# you do not want; and
# is a potential security risk because it exposes an endpoint that is, perhaps not expected, is possibly not used, and is possibly not protected.
If your service unit includes a wsdl with [Concrete WSDL|http://blogs.sun.com/gopalan/entry/wsdl_the_wsdl_model]information the tooling will automatically try to build a Binding Component Service Unit for that concrete binding information - usually a SOAP / HTTP Binding Component Service Unit.
For instance, the [OpenESB Introduction Tutorial|http://wiki.open-esb.java.net/Wiki.jsp?page=OpenESBIntroductionTutorial]uses a BPEL process to orchestrate an EJB which is deployed as a JavaEE SE Service Unit. If you build a solution like this one, you often see a CASA diagram like the one below.
\\
!ejbsu1.JPG!
It shows a link from the BPEL SU to the JavaEE SU. However, it also shows that the EJB exposes its own SOAP endpoint - the _{+}loanProcessorPort{+}_.
h2. How to remove/disable it
There are a few things you can do to get rid of this extra endpoint.
The first is to create an EJB webservice based on an [Abstract WSDL|http://blogs.sun.com/gopalan/entry/wsdl_the_wsdl_model] only. That is, it does not includes any concrete binding information. This feature is now available in NetBeans 6.1 (including the build for JavaCAPS 6).
If your WSDL already includes binding information, the tooling will automatically try to build a Binding Component Service Unit for that concrete binding information - usually a SOAP / HTTP Binding Component Service Unit. In this situation there are two things you can do.
First you can simply right-click on it and delete it from the CASA project. This reduces clutter in your diagram by removing it from the CASA graph but does not actually stop the endpoint from being exposed when the project is deployed
!ejbsu2.JPG!\\
\\
However, the second thing you can do is then to right-click on the JavaEE Service Unit under the _JBI Modules_ folder of the Composite Application project and select _Deployment Settings_. It will bring up the dialog box below which allows you to de-select the _Activate JavaEE Http Port_ checkbox
\\
!ejbsu4.JPG!\\
Deselecting this checkbox means the endpoint will not be available for external clients to interact with the EJB directly.
\\
\\
{toc}
h2. Why it is created
The JavaEE Service Engine in OpenESB and JavaCAPS is a little different from other [JBI|http://wiki.open-esb.java.net/Wiki.jsp?page=LearnJBI]Service Engines.
Most Service Engines are containers which both execute their Service Units and provide the JBI-compliant APIs and functionality to allow those Service Units to operate in a JBI-compliant environment. For instance the [BPEL Service Engine|http://wiki.open-esb.java.net/Wiki.jsp?page=BPELSE] executes one or more bpel processes, each of which are individual Service Units. The BPEL SE implements the necessary functionality to allow those Service Units to:
* be deployed and managed based on the JBI lifecycle
* to turn interactions to and from those service units into JBI compliant Message Exchanges based on Normalised Messages
* implement Quality of Service features such as transactionality, security, etc.
all without the developer having to worry about implementing these things in the bpel process itself.
In contrast the JavaEE SE acts as a bridge between the JBI Container and service consumers and providers executing in other JavaEE containers - the EJB Container and the Web Container. It still provides the necessary JBI-compliant APIs but the "Service Units" are actually regular EJBs and webapps running in the AppServer.
!javaeesu3.JPG!
The way this works in OpenESB/JavaCAPS, is that you develop regular JavaEE components which are webservice consumers and providers. If you deploy these as part of a JBI Service Assembly (a Netbeans Composite Application project) then references are created the JavaEE SE and all communication to and from these "services" are intercepted and passed from the NMR, through the JavaEE SE to the webapp or EJB, rather than going over the wire. For instance, you can create a JavaEE Service Unit by building a regular [JAX-WS compliant webservice|http://www.netbeans.org/kb/60/websvc/jax-ws.html] and including it in a Composite Application project.
This is described in more detail in the following references:
* [JBI and Java EE - Implement SOA with Java EE & JBI | https://open-esb.dev.java.net/public/whitepapers/ImplementingSOA.pdf]
* [Bridge the gap between Java EE & JBI | http://weblogs.java.net/blog/binod/archive/2006/07/java_ee_service_1.html]\\
One consequence of this approach is that the JavaEE Service Unit (the JAX-WS EJB) will have its own webservice endpoint when deployed in the AppServer, plus, the endpoint it provides through the JavaEE Service Engine to other services running in the JBI container. If you only want to communicate to/from other services in the JBI container then you get an extra soap binding which,
# you do not want; and
# is a potential security risk because it exposes an endpoint that is, perhaps not expected, is possibly not used, and is possibly not protected.
If your service unit includes a wsdl with [Concrete WSDL|http://blogs.sun.com/gopalan/entry/wsdl_the_wsdl_model]information the tooling will automatically try to build a Binding Component Service Unit for that concrete binding information - usually a SOAP / HTTP Binding Component Service Unit.
For instance, the [OpenESB Introduction Tutorial|http://wiki.open-esb.java.net/Wiki.jsp?page=OpenESBIntroductionTutorial]uses a BPEL process to orchestrate an EJB which is deployed as a JavaEE SE Service Unit. If you build a solution like this one, you often see a CASA diagram like the one below.
\\
!ejbsu1.JPG!
It shows a link from the BPEL SU to the JavaEE SU. However, it also shows that the EJB exposes its own SOAP endpoint - the _{+}loanProcessorPort{+}_.
h2. How to remove/disable it
There are a few things you can do to get rid of this extra endpoint.
The first is to create an EJB webservice based on an [Abstract WSDL|http://blogs.sun.com/gopalan/entry/wsdl_the_wsdl_model] only. That is, it does not includes any concrete binding information. This feature is now available in NetBeans 6.1 (including the build for JavaCAPS 6).
If your WSDL already includes binding information, the tooling will automatically try to build a Binding Component Service Unit for that concrete binding information - usually a SOAP / HTTP Binding Component Service Unit. In this situation there are two things you can do.
First you can simply right-click on it and delete it from the CASA project. This reduces clutter in your diagram by removing it from the CASA graph but does not actually stop the endpoint from being exposed when the project is deployed
!ejbsu2.JPG!\\
\\
However, the second thing you can do is then to right-click on the JavaEE Service Unit under the _JBI Modules_ folder of the Composite Application project and select _Deployment Settings_. It will bring up the dialog box below which allows you to de-select the _Activate JavaEE Http Port_ checkbox
\\
!ejbsu4.JPG!\\
Deselecting this checkbox means the endpoint will not be available for external clients to interact with the EJB directly.
\\
\\