“Unable to Locate Activated Endpoint” when reusing a common service

We have one EJB for sending email notifications. We did not use Email BC because we have to format the email and we did not want to do that in every BPEL. We have atleast 30 service assemblies using this EJB. Everytime we shutdown one of the service assemblies, this EJB stops working. We will not get email notifications. When we went through the logs we found that we are getting “Unable to locate activated endpoint” error. Usually this error occurs when the service is not deployed or not reachable. On Further investigation we were able to make out that when we shutdown any of the service assemblies which uses this EJB it affects all the others. We thought it is a bug with GlassFishESB. As a workaround, we had to restart all the service assemblies which uses this EJB.

I wanted to fix this Bug. I wrote two service assemblies TestCA1 and TestCA2, and one CommonEJB. TestCA1 and TestCA2 will receive a http request, invoke the CommonEJB and return the string from CommonEJB. This is a plain echo service. For invoking this EJB from BPEL I need to have the WSDL of this EJB. So I used “Generate and Copy WSDL..” option to copy the WSDL into the BPEL folder. I was able to cleanly reproduce the problem. Everytime I shutdown TestBP1, TestBP2 was not working and vice versa. I turned the JBI logging to finest. And this is what I found when I shutdown TestCA1:

[#|2012-02-14T19:33:41.322+0530|FINE|sun-appserver2.1|com.sun.jbi.messaging|_ThreadID=1015;_ThreadName=TestCA1-sun-http-binding;ClassName=com.sun.jbi.messaging.EndpointRegistry;MethodName=removeEndpoint;_RequestID=42f05924-ebc6-43ad-8a4d-539c8d910bf3;|Removed endpoint: http://test.logicoy.com/,CommonEJBService,CommonEJBPort|#]

So it is clear that it is removing this endpoint from EndpointRegistry. But why does it remove this endpoint? Can’t the JBI understand that it is a common service? The answer is No. It cannot. This is what I found when we shutdown a service assembly:
- It looks at the jbi.xml for all the endpoints under connections.

- It remove all the endpoints from EndpointRegistry by supplying endpoint names.

So it does not know if the endpoint is a common endpoint or not. But from the above log, I can clearly see that an endpoint is uniquely identified by namespace, service name and port name, which is exactly what I have in the WSDLs of both the service assemblies.

So the solution is : simple, have separate WSDLs for each service assembly with unique service name and port name. After I renamed the service name and port name in the common EJB’s wsdl, the problem is solved.

One additional note. I think this same problem will occur even when we try to reuse a common Service Assembly. The solution is same, use separate wsdl for each service assembly and have unique service name and port name.

Posted in GlassFishESB, openesb | Leave a comment

LogiCoy Presenting at Open Source Skunkworks at EHI

LogiCoy will be at Open Source Skunkworks at EHI Live

NEC Birmingham 7-8th Nov 2011

Booth E71
Presenting OpenESB, Business Integration. Come and see us there.

http://www.ehi.co.uk/events/ehi-live/

Posted in Uncategorized | Leave a comment

What do you do if you get “Address already in use (9080) when restarting OpenESB”?

Port 9080 is the default port used by the HTTP BC.
The likely cause is that an instance of GlassFish is still running while starting a new one.
First try shutting down gracefully using asadmin.

After you stop glassfish, to make sure all processes are gone and not holding any ports, you can do a
ps -ef | grep glassfish
and if there are any processes left, do a
kill -9 pid
on those glassfish processes.

Then I would wait a minute and restart glassfish.
If the issue persists, you need to find which process is holding the port.
You can do
ps –ef | grep port#
or better yet do a,
lsof –V | grep port#
which will give you the pid of the process holding the port. Then you can either kill the process or determine to change the port for the HTTP BC.

Similar issue can happen in a GlassFish with multiple instances if the HTTP BC port numbers are not unique in different instances.
You need to ensure that port numbers are unique.

Posted in GlassFishESB, openesb | Tagged , , , | Leave a comment

Please support OpenESB community and register for the summit

Extend your support to OpenESB community and register for the event:
http://www.logicoy.com/second-openesb-summit-organized-logicoy-9th-and-10th-may-2011

http://openesb.eventbrite.com/

Posted in Uncategorized | Leave a comment

Interested in sponsoring OpenESB summit?

Interested in sponsoring OpenESB summit? Sponsor details here

Posted in GlassFishESB, openesb | Tagged , | Leave a comment

LogiCoy Organizes US OpenESB summit

LogiCoy Organizes US OpenESB summit. To know more visit: US OpenESB summit

Posted in GlassFishESB, openesb | Tagged , | Leave a comment

Is OpenESB dead ?

Read here a white paper on past,present and future of OpenESB.

Posted in GlassFishESB, openesb | Tagged , | Leave a comment

A Comparative study of OpenESB and other JBI based open source ESB

A Comparative study of OpenESB and other JBI based ESB: Coming soon…

Posted in openesb | Tagged , | Leave a comment

OpenESB past,present and future

Read LogiCoy white paper on OpenESB past,present and future.
OpenESB white paper

Posted in openesb | Tagged , | Leave a comment

Learn JBI : The backbone behined OpenESB

What is JBI ?
Java Business Integration (JBI) is a specification developed under the Java Community Process (JCP) for an approach to implementing a service-oriented architecture (SOA).
The JCP reference is:
JBI 1.0 – JSR 208
JBI 2.0 – JSR 312

Following open-source JBI implementations are available

  • Open ESB
  • Petals ESB
  • Apache ServiceMix
  • FUSE ESB (enterprise ServiceMix) – compliant JSR 208
  • Bostech ChainBuilder ESB
  • Mule. Though not a JBI compliant container by itself, Mule provides interoperability with JBI containers. There is a separate Mule-JBI project that is to address this JBI compliance issue.
  • JBI is built on a Web Services model and provides a pluggable architecture for a container that hosts service producer and consumer components. Services connect to the container via binding components (BC) or can be hosted inside the container as part of a service engine (SE). The services model used is Web Services Description Language 2.0. The central message delivery mechanism, the normalized message router (NMR), delivers normalized messages via one of four Message Exchange Patterns (MEPs), taken from WSDL 2.0:

    1. In-Only: A standard one-way messaging exchange where the consumer sends a message to the provider that provides only a status response.
    2. Robust In-Only: This pattern is for reliable one-way message exchanges. The consumer initiates with a message to which the provider responds with status. If the response is a status, the exchange is complete, but if the response is a fault, the consumer must respond with a status.
    3. In-Out: A standard two-way message exchange where the consumer initiates with a message, the provider responds with a message or fault and the consumer responds with a status.
    4. In Optional-Out: A standard two-way message exchange where the provider’s response is optional.

    JBI Basics

    * Messaging based, plug-in architecture
    * This infrastructure allows third-party components to be plugged in” to a standard infrastructure, and allows those components to interoperate
    * It does not define the pluggable components themselves, but the container/framework interfaces, behavior and services
    * Is itself a service-oriented architecture
    * Components describe their capabilities via WSDL
    * Key components
    o Service Engines (SE) – pluggable business logic
    o Binding Components (BC) – pluggable external connectivity
    o Normalized message router (NMR)

    Service Engine (SE)

    * Container for hosting Service Units that provide Business Logic.
    * These provide an abstract WSDL interface to describe the service.
    * The SU is exposed as an endpoint on the NMR.
    o Examples include: BPEL SE, JavaEE SE, IEP SE, POJO SE, JRuby SE

    Binding Component (BC)

    * Container for hosting Service Units that define external connectivity.
    * The SU is exposed as an endpoint on the NMR
    * BCs expose a WSDL-described interface to other SUs.
    * BCs expose a protocol-specific interface to clients and systems that are external to environment.
    * BCs map outgoing requests from a service invocation from another SU to protocol specific invocation to an external system
    * BCs map incoming requests from a protocol specific invocation from an external system to a service invocation of another SU.
    o Examples include: JMS BC, HTTP BC, REST BC, Email BC

    Service Units and Service Assemblies

    * primary unit of functionality in JBI
    * Service Units (SU) can be deployed to installed BCs and SEs
    o This allows the deployment (and undeployment) of component-specific artifacts (e.g. concrete WSDLs)
    o Can describe what services are provided and consumed by the component
    o Besides the standard descriptor, the component is responsible for interpreting the contents of the SU jar
    * A Service Assembly (SA) can package multiple service units and defines the target components to deploy them to

    Normalized Messages

    * Standard format forms the foundation of the interoperability between JBI components
    * The primary content of a normalized message is always XML
    * There are two distinct parts to a normalized message
    o Content – the message data, as described by the abstract WSDL (represented as an XML transform Source, e.g. DOM or SAX Source)
    o Context (Meta-data in message properties, such as a security subject or protocol headers)

    For latest openesb updates, visit the link at : http://www.logicoy.com/openesb

    Posted in openesb | Tagged , , | Leave a comment