Can blacktie's atmi services be used by tuxedo client?

[sunn_lc]

Hi,

Can blacktie's atmi services be used by tuxedo clients?

Should I advertise the blacktie's atmi services into tuxedo's bbl?

Thanks.

Best regards.

Sunny

[zhfeng]

Blacktie could be a replacement of Tuxedo, So you can try to recompile your service and client with Blacktie.

I think it's possible to make minimal changes in your source codes.
If there is any problem, you can check http://www.jboss.org/community/wiki/BuildingXATMIservicesandclients

It's no need to advertise the blacktie's atmi services into BBL.
Hope this is helpful,

Amos

[sunn_lc]

Hi Amos,

Here is a multi-vendor environment.

And there are many tuxedo workstation clients that have to access the tuxedo services by "WSNADDR", not by corba name.

I think the blacktie's framework doesn't provide services by this way.

I'd like find a way to make interconnection between

the tuxedo services and the services provided by a J2EE server.

Thanks.

Best regards.

Sunny

[tomjenkinson]

Hi Sunny,

Although it is one of our long-term goals to introduce wire-protocol compatibility with other XATMI implementations unfortunately at the moment due to resource constraints we are unable to offer this as a feature. That said we are always more than happy to work with others in the community to deliver features. As you can see from Jira we have a long standing feature request to add this: https://jira.jboss.org/jira/browse/BLACKTIE-64, if you would like to work with us on this feature that would be great! We intend to make this the focus of version 3 of the software, we are currently working on version 2 - administration.

Until that point I would suggest one of the following:
1. Deploy a BlackTie client as well as your existing client (if this is feasible) - this will however partition your application between your existing deployment and BlackTie
2. Provide an adapter service in your existing deployment that intercepts the clients requests and transforms it into a BlackTie request.

On a different note, I should also mention that the service is actually advertised in JNDI by the JMS queue name, rather than in the CORBA Naming Service. Originally we had a pure CORBA transport which advertised the CORBA object name, but in order to address the questions of high availability and clustering we make the initial connection to the service through JMS, after the initial request is received by the service, the remaining communication takes place over CORBA. Therefore we do not need to advertise the names in the CORBA naming service. The CORBA naming service is now used by BlackTie solely to advertise the name of the Transaction Service (JBoss Transactions).

Hope this helps!
Tom

[8745132]

hi,

is it an error?

                        } else if (message.flags & TPRECVONLY) {
                            toReturn = 0;
                            *event = TPEV_SENDONLY;
                            session->setCanSend(true);
                            session->setCanRecv(false);
                            LOG4CXX_DEBUG(
                                    loggerXATMI,
                                    (char*) "receive TPRECVONLY set constraints session: "
                                            << session->getId() << " send: "
                                            << session->getCanSend()
                                            << " recv: "
                                            << session->getCanRecv());
                        } else if (message.flags & TPSENDONLY) {
                            toReturn = 0;
                            session->setCanSend(true);
                            session->setCanRecv(false);

best regards

Sunny

[tomjenkinson]

Hi Sunny,

I am not sure what you mean? Do you think there is a bug in that code?

Thanks for the feedback!

Tom

[8745132]

Hi Tom,

if (message.flags & TPSENDONLY)

the codes do:

                            session->setCanSend(true);

                            session->setCanRecv(false);

so when

if (message.flags & TPRECVONLY)

the codes should at least do:

                            session->setCanSend(false);
                            session->setCanRecv(true);

not

                         session->setCanSend(true);
                            session->setCanRecv(false);

best regards,

Sunny

[tomjenkinson]

Hi Sunny,

I have now had chance to look into this and you are right that there is a bug there in that code. The actual error is that code should not be handling TPSENDONLY flags in the receive.

The only actor that can receive TPSENDONLY is the service on the initial invocation of tpservice (i.e. tpconnect is the only method that can pass TPSENDONLY as flags according to my understanding of the XATMI specification.

I have committed a fix (i.e. the removal of the code) for this. I did notice we didn't have particularly comprehensive testing of tpsend with TPRECVONLY as the parameter so I added a new test to atmibroker-xatmi/src/test/cpp/TestTPSend.cxx for this.

Thanks very much!

Tom