JTux Tuxedo and Java integration package released

Discussions

News: JTux Tuxedo and Java integration package released

  1. OTP Systems Oy is pleased to announce the availability of JTux version 1.0. JTux is a software package that integrates BEA Tuxedo with Java. Using JTux, Tuxedo customers can write Tuxedo clients and servers in Java and seamlessly integrate a wide range of Java enterprise technologies into their existing Tuxedo infrastructures.

    JTux also features a Tuxedo/JTA transaction management server which enables Tuxedo to manage distributed transactions involving both Java and non-Java based XA resource managers.

    Detailed information about JTux is available at http://www.otpsystems.com

    Threaded Messages (20)

  2. BEA has been having a product for this for a long time.

    Is it possible to call Tuxedo from EJB's without any third part libraries ?
    And to share transaction context ?

    After all Tuxedo is CORBA based.
  3. BEA has been having a product for this for a long time.Is it possible to call Tuxedo from EJB's without any third part libraries ?And to share transaction context ?After all Tuxedo is CORBA based.
    BEA WebLogic Server comes with a built-in Tuxedo bridge "WTC", which supports transactions, queueing, and exposing Tux services as EJBs (or EJBs as Tux services):

    http://e-docs.bea.com/wls/docs81/ConsoleHelp/wtc.html

    In addition, both Tux and WLS support IIOP clients, but I'm not conversant in how extensive this support is:

    http://edocs.bea.com/tuxedo/tux81/overview/corba.htm
    http://edocs.bea.com/wls/docs81/rmi_iiop/index.html

    Tom Barnes, BEA
  4. BEA WebLogic Server comes with a built-in Tuxedo bridge "WTC", which supports transactions, queueing, and exposing Tux services as EJBs (or EJBs as Tux services)
    Is it possible to use WTC bridge with other application servers ?

    For example, we have to support not only WL but also WebSphere because of market adaption.

    Or maybe it's possible with this JTux ?
  5. BEA WebLogic Server comes with a built-in Tuxedo bridge "WTC", which supports transactions, queueing, and exposing Tux services as EJBs (or EJBs as Tux services)
    Is it possible to use WTC bridge with other application servers ?For example, we have to support not only WL but also WebSphere because of market adaption.Or maybe it's possible with this JTux ?
    Yes, this is one of the possible applications of JTux: to integrate Tuxedo with any J2EE application server.
  6. BEA has been having a product for this for a long time.Is it possible to call Tuxedo from EJB's without any third part libraries ?And to share transaction context ?After all Tuxedo is CORBA based.
    BEA WebLogic Server comes with a built-in Tuxedo bridge "WTC", which supports transactions, queueing, and exposing Tux services as EJBs (or EJBs as Tux services)
    There is a fundamental difference between JTux and WTC. JTux allows Tuxedo services written in Java to be hosted on Tuxedo. Instead of writing Tuxedo services as EJBs and hosting them on WebLogic, JTux allows you to write Tuxedo services using Tuxedo's own ATMI API and deploy them directly on Tuxedo, without the need for an external application server and the administrative overhead of a bridge.

    It is interesting to note that OTP Systems has also developed a sister product, called DotTux, that allows Tuxedo services to be written in any programming language targetting the Microsoft .NET Common Language Runtime. Together with JTux, this allows Tuxedo customers to host enterprise application services written in Java, C#, C/C++ and Cobol on a single, integrated application server platform.
  7. You will be able to call tuxedo from EJB using CORBA facilities. But if you want transactions you will not be able to do that.
  8. BEA has been having a product for this for a long time.Is it possible to call Tuxedo from EJB's without any third part libraries ?And to share transaction context ?After all Tuxedo is CORBA based.
    Actually, it is the other way around. BEA's CORBA implementation is based on Tuxedo. Tuxedo itself is based on the Distributed Transaction Processing (DTP) model defined by the OpenGroup (see http://www.opengroup.org/bookstore/catalog/g504.htm). In fact, Tuxedo is the reference implementation for this model and as such the most mature XA transaction manager available on the market.

    What JTux adds to Tuxedo is a mapping of the ATMI API defined by the OpenGroup's DTP model to Java. The ATMI API is a simple, service oriented API for building distributed, transaction oriented applications and was defined long before CORBA and J2EE. The 'old' ATMI API is arguably an order of magnitude easier to use than modern object oriented APIs such as CORBA and EJB.
  9. Also point to be noted is that JTux allows distributed transaction from Tuxedo to the J2EE world, not the other way round. It will pose problem for the projects involving migration from Tuxedo to J2EE. From that perspective, WTC is kind of only choice; but that would bind you to WebLogic appserver. Depnds upon how strogly you need global transaction. With the advent of aysnchronous rpc mechanisms transactions are becoming shaky ground to explore.
  10. Also point to be noted is that JTux allows distributed transaction from Tuxedo to the J2EE world, not the other way round. It will pose problem for the projects involving migration from Tuxedo to J2EE.
    That is true. But the point of JTux is that you don't need to migrate from Tuxedo to J2EE as you can now build your Java based enterprise services directly on Tuxedo. Of course you can argue that J2EE is the future but Tuxedo has a couple of advantages over J2EE.

    First of all, Tuxedo is programming language agnostic. It provides transactions, security, load balancing, etc, etc, without tying you to a particular programming language. This allows you to write your enterprise services in Java, C#, C, C++, COBOL, Python, whatever, and deploy them all on Tuxedo. From an administrative perspective this is a big advantage compared to having separate application servers and connect them all together with bridges.

    A second big advantage of Tuxedo is simplicity. The Tuxedo API is so simple that, in this respect, moving to J2EE is a step backward rather than forward. The Tuxedo API supports client/server, message queuing and publish/subscribe communication in a single API based on a consistent, service oriented architecture. The Tuxedo API is refreshingly free of connections, sessions, factories, pools, and other object oriented artifacts inherent to using J2EE.
  11. Hi, can you confirm me that throught JTMS, Jserver proceses can both access XA resources (ej XA Pooled DataSouces on Weblogic), and call EJB (hosted on WL) spanning transacional context?

    I've scanned website but I haven't managed to find a data/ejb usage example, just simpapp type examples.

    Nice work BTW. Despite not being J2EE<->Tuxedo bidirectional transactionwise, it can be usefull in Tuxedo Centric existing setups.
  12. Hi, can you confirm me that throught JTMS, Jserver proceses can both access XA resources (ej XA Pooled DataSouces on Weblogic), and call EJB (hosted on WL) spanning transacional context?I've scanned website but I haven't managed to find a data/ejb usage example, just simpapp type examples.Nice work BTW. Despite not being J2EE<->Tuxedo bidirectional transactionwise, it can be usefull in Tuxedo Centric existing setups.
    JTMS/JServer processes can access XA resources as part of Tuxedo managed distributed transactions using any JDBC or JMS driver that provides a faithful implementation of the JTA spec. Standard JTux XA Resource Adapters for JDBC and JMS that enable this are available. Please contact us directly for more information.

    With respect to WebLogic, I am not sure whether the WebLogic JDBC driver you mention can actually be used outside of WebLogic, but if it can then there should be no problem.

    Calling EJBs in the context of the same Tuxedo managed distributed transaction is possible if the application server supports Transaction Inflows. Transaction Inflows are specified by version 1.5 of the J2EE Connector Architecture and allow transactional work performed by a J2EE application server to be controlled by an external transaction manager (such as Tuxedo). We plan to provide a standard JTux XA Resource Adapter for JCA as soon as support for Transaction Inflows starts to appear in the major J2EE application servers.

    Robin Boerdijk
    OTP Systems Oy
  13. Thank you Robin for the info.

    Josep
  14. Choosing a project name[ Go to top ]

    I wish people would do their homework before choosing a project name. JTux, as in Java-To-Unix, has been around for a little while now and is popular enough to earn itself the number 1 seat on a google search for JTux. Tip: When choosing a name for your project, the minimum you should do is google for it :-)

    How about considering a different name - say - Juxedo?

    - Mike
  15. Choosing a project name[ Go to top ]

    I wish people would do their homework before choosing a project name. JTux, as in Java-To-Unix, has been around for a little while now and is popular enough to earn itself the number 1 seat on a google search for JTux. Tip: When choosing a name for your project, the minimum you should do is google for it :-)How about considering a different name - say - Juxedo?- Mike
    Good point. But JTux, as in Java-for-Tuxedo, already ranks #2 on Google. Let's see who's number 1 in a couple of days ;-)
  16. Choosing a project name[ Go to top ]

    Just remember the Firebird / Firefox fiasco in your quest to become the most popular "jtux" project ;-)
  17. Is it as fast as the C service?
    Can I use the c# client to call the JTux service?
    Thx
  18. Is it as fast as the C service?
    No, but the overhead involved when calling Tuxedo services written in Java is negligible for all but the simplest Tuxedo services. Depending on the optimization capabilities of the JVM, Tuxedo services written in Java can even be faster than their C equivalents.
    Can I use the c# client to call the JTux service?
    Yes. For a client, JTux services are indistinguishable from Tuxedo services written in C/C++ or any other programming language for that matter. So a C# client can invoke JTux services just like a C/C++ client can.

    Robin Boerdijk
    OTP Systems Oy
  19. I need some compare data[ Go to top ]

    Do you have test the performance between C service and JTux service ?
    Where can I found these performance data?
    Thanks!
  20. I need some compare data[ Go to top ]

    Do you have test the performance between C service and JTux service ?Where can I found these performance data?Thanks!
    It is very hard to produce performance data that are meaningful for your specific situation. That's why I recommend to download a JTux evaluation copy from our website and try it out yourself. After downloading, you will have the contact information through which you can reach us directly should you need any assistence in your performance comparison.

    Regards,

    Robin Boerdijk
    OTP Systems Oy
  21. Where can I find the performance compared data between the JTux service and
    C service?

    Thanks