Microsoft Transaction Server (MTS)/COM+ Under Linux?

[Timothy Holtom]

I'm totally new to Linux.

Can anyone tell me whether there is a Linux equivalent of Microsoft's Transaction
Server now bundled up into COM+ ?

I'm looking for a Linux version of a componentized scalable transaction server.
Does such a beast exist?


Thanks,

Tim

[mayur]

Hi Tim,
U can register in EJB server & work out as simillar to MTS.

Mayur

[William Rose]

"Timothy Holtom" <Timothy.Holtom@getronics.com> wrote:
>
>I'm totally new to Linux.
>
>Can anyone tell me whether there is a Linux equivalent of Microsoft's Transaction
>Server now bundled up into COM+ ?
>
>I'm looking for a Linux version of a componentized scalable transaction
server.
> Does such a beast exist?
>
>
>Thanks,
>
>Tim
>

I would like to apologize for the open source community, and state that it
is no wonder that companies like MS are currently winning the battle. With
responses like the ones on this list, the major companies fuel their fight
against the Open Source community, showing that open source is more about
a rebellious attitude and not beneficial to the growth of a company. Could
someone please reply to this question is a professional way?

Billy Rose

[Search Engine]

>I would like to apologize for the open source community, and state that it
>is no wonder that companies like MS are currently winning the battle. With
>responses like the ones on this list, the major companies fuel their fight
>against the Open Source community, showing that open source is more about
>a rebellious attitude and not beneficial to the growth of a company. Could
>someone please reply to this question is a professional way?
>
>Billy Rose

Haha. You morons. There is no professional way of doing things in the Linux
world. And there is no way you can find anything equivalent to MTS on a Linux
box. Just use Win2K.

[Condor]

With the structure of Linux (namely being yet another version of UNIX) the
only means you have to have an MTS equivalent is to run J2EE and use Java
Beans. This provides some resemblance of component development and component
management.....but with caviates (of course). First you are language dependant
while MTS is language independant and you are also (in both cases) vendor
dependant. Whichever J2EE vendor you code under, you develope some chains
that bind you to that client.

The other issues involve first the J2EE 1.1 specs which disallow multithread
objects. Thus if you have 5 clients running recipient objects and they all
want to use a calculator object, they are single threaded into that object.
This seems to be addressed in the 2.0 specs, but those are still in beta
state.

Third is that a session java bean requires (emphasize requires) an entity
java bean. Hmmm ... is that bad? Yes, because it forces maintaining state.
As we in the COM world have known for years, a stateful transaction will
not scale to the same levels that a stateless transaction will.

Finally you have the major issue that no J2EE vendor is willing to publish
benchmarks. This is a major issue that I would be in fear of from the implementation
standpoint. Dig up the IBM system journals until you find the one devoted
to the San Francisco Project. This was one of IBM's first major java implementations.
My take on the article is that they spent 5 years rewriting code and rewriting
the JVM internals until they got decent response time.

There are ways that you can write COM under UNIX but it is very complex and
not a pretty thing to do. That would be a way that you could have a UNIX-based
COM object bind to an existing MTS server. However....we are talking about
LINUX not UNIX and I do not know of ANY conventions that exist under SOlARIS
(for example) apply to LINUX. I would not be afraid to hazard a guess that
the Open Source bigots made sure that you could not do any COM under LINUX.

[Jeff Vance]

"Condor" <theRealCondor@yahoo.com> wrote:
>
>With the structure of Linux (namely being yet another version of UNIX) the
>only means you have to have an MTS equivalent is to run J2EE and use Java
>Beans.

Without getting into the remainder of the very superficial overview of a
J2EE alternative to COM/DCOM, there are other options. A quick search engine
query and a few links showed that Software AG produces a COM/DCOM implementation
for Linux.

http://www.softwareag.com/entirex/do...5Fdownload.htm

The package is available for a free download at the link above. I'm not
an advocate of either MS or Java technologies, but let's at least argue based
on facts.

[Gustavo Ramos]

Hello, a "open source bigots" developer respond

I am MFC-ATL-COM/DCOM-etc developer too, and I can tell you that MS has impressive
technologies... But many MS-technologies are not standard, and they don't
want that "intelectual property cancer", as textually said by Gates, referring
to the open source. Well, let's me say something about standards and the
open source software:

Most flavours of Unix-like OS's (HP-UX, Solaris, AIX, Linux, BSD, etc.) use
the standards of POSIX. A list of guides and other formal literature are
found here:

http://standards.ieee.org/reading/ie...ription/posix/

So, the "open source bigots" are well organized, and can do systems that
runs in any posix-compliant system (call it unix-like system, if you want),
and sure, there exist "conventions", as you stated. But they are not AnyCompany-property.

There are specifications about distributed computing, not specific to linux,
but applies, too. The Common Object Request Broker Architecture -CORBA (www.corba.org)-
is a wide used specification, and it has several years (since 1994, I think),
so, it is much more reliable that COM/COM+/DCOM (don't believe that MS has
invented the wheel). This specification is not bound to any company, instead,
it exist a lot of implementations, from different vendors/organizations.
So, if you follow the CORBA standards, you can make a system that works across
any platform and any language, but the implementations on all running systems
must use a CORBA compliant server. You can choose an implementation, depending
on your needs. A large list of vendors are in

http://www.cetus-links.org/oo_object...t_brokers.html

If you intend to use MS DCOM components in a Linux box, you can use a CORBA/DCOM
bridge. You can found a the list in the previous URL.

Regards,

Gustavo



"Condor" <theRealCondor@yahoo.com> wrote:
>
>With the structure of Linux (namely being yet another version of UNIX) the
>only means you have to have an MTS equivalent is to run J2EE and use Java
>Beans. This provides some resemblance of component development and component
>management.....but with caviates (of course). First you are language dependant
>while MTS is language independant and you are also (in both cases) vendor
>dependant. Whichever J2EE vendor you code under, you develope some chains
>that bind you to that client.
>
>The other issues involve first the J2EE 1.1 specs which disallow multithread
>objects. Thus if you have 5 clients running recipient objects and they
all
>want to use a calculator object, they are single threaded into that object.
> This seems to be addressed in the 2.0 specs, but those are still in beta
>state.
>
>Third is that a session java bean requires (emphasize requires) an entity
>java bean. Hmmm ... is that bad? Yes, because it forces maintaining state.
> As we in the COM world have known for years, a stateful transaction will
>not scale to the same levels that a stateless transaction will.
>
>Finally you have the major issue that no J2EE vendor is willing to publish
>benchmarks. This is a major issue that I would be in fear of from the implementation
>standpoint. Dig up the IBM system journals until you find the one devoted
>to the San Francisco Project. This was one of IBM's first major java implementations.
> My take on the article is that they spent 5 years rewriting code and rewriting
>the JVM internals until they got decent response time.
>
>There are ways that you can write COM under UNIX but it is very complex
and
>not a pretty thing to do. That would be a way that you could have a UNIX-based
>COM object bind to an existing MTS server. However....we are talking about
>LINUX not UNIX and I do not know of ANY conventions that exist under SOlARIS
>(for example) apply to LINUX. I would not be afraid to hazard a guess that
>the Open Source bigots made sure that you could not do any COM under LINUX.
>

[Gustavo Ramos]

I forgot something:

One CORBA implementation for linux is Bonobo, which cames from the gnome
project.

"Gustavo Ramos" <grrp@yahoo.com> wrote:
>
>Hello, a "open source bigots" developer respond
>
>I am MFC-ATL-COM/DCOM-etc developer too, and I can tell you that MS has
impressive
>technologies... But many MS-technologies are not standard, and they don't
>want that "intelectual property cancer", as textually said by Gates, referring
>to the open source. Well, let's me say something about standards and the
>open source software:
>
>Most flavours of Unix-like OS's (HP-UX, Solaris, AIX, Linux, BSD, etc.)
use
>the standards of POSIX. A list of guides and other formal literature are
>found here:
>
>http://standards.ieee.org/reading/ie...ription/posix/
>
>So, the "open source bigots" are well organized, and can do systems that
>runs in any posix-compliant system (call it unix-like system, if you want),
>and sure, there exist "conventions", as you stated. But they are not AnyCompany-property.
>
>There are specifications about distributed computing, not specific to linux,
>but applies, too. The Common Object Request Broker Architecture -CORBA (www.corba.org)-
>is a wide used specification, and it has several years (since 1994, I think),
>so, it is much more reliable that COM/COM+/DCOM (don't believe that MS has
>invented the wheel). This specification is not bound to any company, instead,
>it exist a lot of implementations, from different vendors/organizations.
>So, if you follow the CORBA standards, you can make a system that works
across
>any platform and any language, but the implementations on all running systems
>must use a CORBA compliant server. You can choose an implementation, depending
>on your needs. A large list of vendors are in
>
>http://www.cetus-links.org/oo_object...t_brokers.html
>
>If you intend to use MS DCOM components in a Linux box, you can use a CORBA/DCOM
>bridge. You can found a the list in the previous URL.
>
>Regards,
>
>Gustavo
>
>
>
>"Condor" <theRealCondor@yahoo.com> wrote:
>>
>>With the structure of Linux (namely being yet another version of UNIX)
the
>>only means you have to have an MTS equivalent is to run J2EE and use Java
>>Beans. This provides some resemblance of component development and component
>>management.....but with caviates (of course). First you are language dependant
>>while MTS is language independant and you are also (in both cases) vendor
>>dependant. Whichever J2EE vendor you code under, you develope some chains
>>that bind you to that client.
>>
>>The other issues involve first the J2EE 1.1 specs which disallow multithread
>>objects. Thus if you have 5 clients running recipient objects and they
>all
>>want to use a calculator object, they are single threaded into that object.
>> This seems to be addressed in the 2.0 specs, but those are still in beta
>>state.
>>
>>Third is that a session java bean requires (emphasize requires) an entity
>>java bean. Hmmm ... is that bad? Yes, because it forces maintaining state.
>> As we in the COM world have known for years, a stateful transaction will
>>not scale to the same levels that a stateless transaction will.
>>
>>Finally you have the major issue that no J2EE vendor is willing to publish
>>benchmarks. This is a major issue that I would be in fear of from the
implementation
>>standpoint. Dig up the IBM system journals until you find the one devoted
>>to the San Francisco Project. This was one of IBM's first major java implementations.
>> My take on the article is that they spent 5 years rewriting code and rewriting
>>the JVM internals until they got decent response time.
>>
>>There are ways that you can write COM under UNIX but it is very complex
>and
>>not a pretty thing to do. That would be a way that you could have a UNIX-based
>>COM object bind to an existing MTS server. However....we are talking about
>>LINUX not UNIX and I do not know of ANY conventions that exist under SOlARIS
>>(for example) apply to LINUX. I would not be afraid to hazard a guess
that
>>the Open Source bigots made sure that you could not do any COM under LINUX.
>>
>

[Christopher Stura]

I used to be an ATL-COM/DCOM programmer and now I program completely in Java/RMI.
Basically I got tierd of being boxed into proprietary technology. In think
that the main problem with anything that microsoft writes is that your applications
will never be able to scale to more than microsoft wants them to. Plus you
can't tell me that COM+ is a serious application server!, I mean you can't
even hot swap your components!!. Plus Microsoft left our persistance I wonder
what they were thinking?, and all the cool caching stuff you can implement
using RMI type technologies. I have an application that runs the menu system
in a CMS system that without its internal memory cache and update pool would
never work. Which means that COM was pretty much out of the question. Plus
when we switched technology, you didn't need a benchmark to clock the results
all you had to do is look at the pages fly down from the server. There was
probably about a 4 second difference in response times.

This all said I think the question remains. Why would you even want to run
Microsoft COM+ technology under linux?

Chris

"Gustavo Ramos" <grrp@yahoo.com> wrote:
>
>Hello, a "open source bigots" developer respond
>
>I am MFC-ATL-COM/DCOM-etc developer too, and I can tell you that MS has
impressive
>technologies... But many MS-technologies are not standard, and they don't
>want that "intelectual property cancer", as textually said by Gates, referring
>to the open source. Well, let's me say something about standards and the
>open source software:
>
>Most flavours of Unix-like OS's (HP-UX, Solaris, AIX, Linux, BSD, etc.)
use
>the standards of POSIX. A list of guides and other formal literature are
>found here:
>
>http://standards.ieee.org/reading/ie...ription/posix/
>
>So, the "open source bigots" are well organized, and can do systems that
>runs in any posix-compliant system (call it unix-like system, if you want),
>and sure, there exist "conventions", as you stated. But they are not AnyCompany-property.
>
>There are specifications about distributed computing, not specific to linux,
>but applies, too. The Common Object Request Broker Architecture -CORBA (www.corba.org)-
>is a wide used specification, and it has several years (since 1994, I think),
>so, it is much more reliable that COM/COM+/DCOM (don't believe that MS has
>invented the wheel). This specification is not bound to any company, instead,
>it exist a lot of implementations, from different vendors/organizations.
>So, if you follow the CORBA standards, you can make a system that works
across
>any platform and any language, but the implementations on all running systems
>must use a CORBA compliant server. You can choose an implementation, depending
>on your needs. A large list of vendors are in
>
>http://www.cetus-links.org/oo_object...t_brokers.html
>
>If you intend to use MS DCOM components in a Linux box, you can use a CORBA/DCOM
>bridge. You can found a the list in the previous URL.
>
>Regards,
>
>Gustavo
>
>
>
>"Condor" <theRealCondor@yahoo.com> wrote:
>>
>>With the structure of Linux (namely being yet another version of UNIX)
the
>>only means you have to have an MTS equivalent is to run J2EE and use Java
>>Beans. This provides some resemblance of component development and component
>>management.....but with caviates (of course). First you are language dependant
>>while MTS is language independant and you are also (in both cases) vendor
>>dependant. Whichever J2EE vendor you code under, you develope some chains
>>that bind you to that client.
>>
>>The other issues involve first the J2EE 1.1 specs which disallow multithread
>>objects. Thus if you have 5 clients running recipient objects and they
>all
>>want to use a calculator object, they are single threaded into that object.
>> This seems to be addressed in the 2.0 specs, but those are still in beta
>>state.
>>
>>Third is that a session java bean requires (emphasize requires) an entity
>>java bean. Hmmm ... is that bad? Yes, because it forces maintaining state.
>> As we in the COM world have known for years, a stateful transaction will
>>not scale to the same levels that a stateless transaction will.
>>
>>Finally you have the major issue that no J2EE vendor is willing to publish
>>benchmarks. This is a major issue that I would be in fear of from the
implementation
>>standpoint. Dig up the IBM system journals until you find the one devoted
>>to the San Francisco Project. This was one of IBM's first major java implementations.
>> My take on the article is that they spent 5 years rewriting code and rewriting
>>the JVM internals until they got decent response time.
>>
>>There are ways that you can write COM under UNIX but it is very complex
>and
>>not a pretty thing to do. That would be a way that you could have a UNIX-based
>>COM object bind to an existing MTS server. However....we are talking about
>>LINUX not UNIX and I do not know of ANY conventions that exist under SOlARIS
>>(for example) apply to LINUX. I would not be afraid to hazard a guess
that
>>the Open Source bigots made sure that you could not do any COM under LINUX.
>>
>

[Jason Stewart]

Why would someone want to run COM+ under linux? It would only ruin the stability
of the Box!

Keep the MS products until the end of the SDLC, then go to a unix based CORBA
solution!

"Gustavo Ramos" <grrp@yahoo.com> wrote:
>
>Hello, a "open source bigots" developer respond
>
>I am MFC-ATL-COM/DCOM-etc developer too, and I can tell you that MS has
impressive
>technologies... But many MS-technologies are not standard, and they don't
>want that "intelectual property cancer", as textually said by Gates, referring
>to the open source. Well, let's me say something about standards and the
>open source software:
>
>Most flavours of Unix-like OS's (HP-UX, Solaris, AIX, Linux, BSD, etc.)
use
>the standards of POSIX. A list of guides and other formal literature are
>found here:
>
>http://standards.ieee.org/reading/ie...ription/posix/
>
>So, the "open source bigots" are well organized, and can do systems that
>runs in any posix-compliant system (call it unix-like system, if you want),
>and sure, there exist "conventions", as you stated. But they are not AnyCompany-property.
>
>There are specifications about distributed computing, not specific to linux,
>but applies, too. The Common Object Request Broker Architecture -CORBA (www.corba.org)-
>is a wide used specification, and it has several years (since 1994, I think),
>so, it is much more reliable that COM/COM+/DCOM (don't believe that MS has
>invented the wheel). This specification is not bound to any company, instead,
>it exist a lot of implementations, from different vendors/organizations.
>So, if you follow the CORBA standards, you can make a system that works
across
>any platform and any language, but the implementations on all running systems
>must use a CORBA compliant server. You can choose an implementation, depending
>on your needs. A large list of vendors are in
>
>http://www.cetus-links.org/oo_object...t_brokers.html
>
>If you intend to use MS DCOM components in a Linux box, you can use a CORBA/DCOM
>bridge. You can found a the list in the previous URL.
>
>Regards,
>
>Gustavo
>
>
>
>"Condor" <theRealCondor@yahoo.com> wrote:
>>
>>With the structure of Linux (namely being yet another version of UNIX)
the
>>only means you have to have an MTS equivalent is to run J2EE and use Java
>>Beans. This provides some resemblance of component development and component
>>management.....but with caviates (of course). First you are language dependant
>>while MTS is language independant and you are also (in both cases) vendor
>>dependant. Whichever J2EE vendor you code under, you develope some chains
>>that bind you to that client.
>>
>>The other issues involve first the J2EE 1.1 specs which disallow multithread
>>objects. Thus if you have 5 clients running recipient objects and they
>all
>>want to use a calculator object, they are single threaded into that object.
>> This seems to be addressed in the 2.0 specs, but those are still in beta
>>state.
>>
>>Third is that a session java bean requires (emphasize requires) an entity
>>java bean. Hmmm ... is that bad? Yes, because it forces maintaining state.
>> As we in the COM world have known for years, a stateful transaction will
>>not scale to the same levels that a stateless transaction will.
>>
>>Finally you have the major issue that no J2EE vendor is willing to publish
>>benchmarks. This is a major issue that I would be in fear of from the
implementation
>>standpoint. Dig up the IBM system journals until you find the one devoted
>>to the San Francisco Project. This was one of IBM's first major java implementations.
>> My take on the article is that they spent 5 years rewriting code and rewriting
>>the JVM internals until they got decent response time.
>>
>>There are ways that you can write COM under UNIX but it is very complex
>and
>>not a pretty thing to do. That would be a way that you could have a UNIX-based
>>COM object bind to an existing MTS server. However....we are talking about
>>LINUX not UNIX and I do not know of ANY conventions that exist under SOlARIS
>>(for example) apply to LINUX. I would not be afraid to hazard a guess
that
>>the Open Source bigots made sure that you could not do any COM under LINUX.
>>
>

[Aaron Sevivas]

"Condor" <theRealCondor@yahoo.com> wrote:
>
>The other issues involve first the J2EE 1.1 specs which disallow >multithread
>objects.

Thats a good thing. No syncronization needed. Same as MTS/COM+ and .NET
Server Services container

>Thus if you have 5 clients running recipient objects and they all
>want to use a calculator object, they are single threaded into that object.

Not true. if 5 clients want to use a Calculator.class 5 new calculators
are created.

>Third is that a session java bean requires (emphasize requires) an entity
>java bean.

again, not true. Quote from the spec:

"A client of an entity object can be another enterprise bean deployed in
the same or different Container;
or a client can be an arbitrary Java program, such as an application, applet,
or servlet."

You don't HAVE to make an entity bean unless you need an entity bean. A
good design practice is to use the Facade pattern of putting a session bean
in front of an entity BUT most enterprise developers are considering getting
rid of the use of entities altogether and just use session beans that access
dbs in chunks instead of record by record due to performance issues.

> As we in the COM world have known for years, a stateful transaction will
>not scale to the same levels that a stateless transaction will.

Java world knows this too, but like in the M$ world, theres alot of developers
who just dont get it.

>
>Finally you have the major issue that no J2EE vendor is willing to publish
>benchmarks.


http://ecperf.theserverside.com/ecpe...en_performance

http://www.cmis.csiro.au/adsat/j2eev2.htm

Regarding the initial poster's question of whether theres an application
server for linux equivalent to MTS: Yes, theres lots, Weblogic App Server,
the free JBoss, IPlanet, the list goes on and on. These app servers host
J2EE EJB components (Equivalent in principle to COM components OR the new
.NET components). Writing your first EJB is going to feel alot more complex
than writing your first COM component, but give it a try at java.sun.com.
You'll catch on in no time!

~ aaron sevivas

[Bill]

"Timothy Holtom" <Timothy.Holtom@getronics.com> wrote:
>Can anyone tell me whether there is a Linux equivalent of Microsoft's Transaction
>Server now bundled up into COM+ ?

> Does such a beast exist?

I'm not sure anyone truly understood the question, as I still don’t see an
answer.

The question is: ‘Is there a Linux PRODUCT that is functionally equivalent
to MTS?’ Forget the COM stuff. The point is that if one has a “server”
object running on their desktop (OK, it’s COM for a MS desktop) MTS allows
it to be installed on a network server, registered on the client, and it
becomes a working remote application. With very little effort a user can
run server code on a remote server. While it might not be applicable to
a large-scale install, a three-user system works just fine.

So we ask again, does the Linux community have anything that will manage
the application on the server end and automatically take care of the communication
from the desktop to the application?

If I read the thread properly the answer is NO, go write it yourself…

[aaronsevivas]

Originally posted by Bill
"Timothy Holtom" <Timothy.Holtom@getronics.com> wrote:
>Can anyone tell me whether there is a Linux equivalent of Microsoft's Transaction
>Server now bundled up into COM+ ?

> Does such a beast exist?

I'm not sure anyone truly understood the question, as I still don’t see an
answer.

The question is: ‘Is there a Linux PRODUCT that is functionally equivalent
to MTS?’ Forget the COM stuff.

Hi Bill,

When you talk about MTS, you talk about an application container. This is what you have to understand. What runs WITHIN the application container (MTS specifically) IS COM. So one cannot just say 'Forget the COM stuff' when you talk about MTS, because everything that runs within MTS IS COM.

The point is that if one has a “server”
object running on their desktop (OK, it’s COM for a MS desktop) MTS allows
it to be installed on a network server, registered on the client, and it
becomes a working remote application. With very little effort a user can
run server code on a remote server. While it might not be applicable to
a large-scale install, a three-user system works just fine.

So we ask again, does the Linux community have anything that will manage
the application on the server end and automatically take care of the communication
from the desktop to the application?

If I read the thread properly the answer is NO, go write it yourself…

The answer is a definitive YES. No ifs, ands or buts allowed. The communication between the client and the server in the scenario you described is called DCOM in the Microsoft world (.NET remoting in the .NET world or u can use SOAP). The application container is called MTS in the MS world and in the java world its called JBOSS or WEBLOGIC or iPLANET or.. etc..

Now in the Java world, this communication is called RMI (remote method invocation). The communication is automatically configurable (you still need to supply the url to the server, just like the MS world) where the necessary files are downloaded to the client machine. Here is an example

http://java.sun.com/j2ee/tutorial/1_...on2.html#65146

The code running under MTS is called COM components in the MTS MS world, the code running under JBOSS, or WEBLOGIC. or iPLANET etc is called session beans or entity beans. Again, thats all there is 2 it.

Understand that the java platform and the .NET platform match each other almost feature by feature in todays world. Although there are some improvements of one over the other (J2EE had much more going for it than COM, .NET I believe has much more potential than J2EE..) But the fight will rage on..

Hope that helped.

[gjunker]

No, no one understood the question.

MTS = Microsoft TRANSACTION Server. Emphasis on the "TRANSACTION". Anyone who thinks that MTS is the same thing as a J2EE App Server simply does not understand what MTS is for.

I have not found a Distributed Transaction Coordinator for Linux. Something that can coordinate transactions not only across process boundaries but across application domains (for example, rolling back transactions on MySQL in the event of a failure within the transaction boundaries in, say, a PHP page).

[aaronsevivas]

Originally posted by gjunker
No, no one understood the question.

MTS = Microsoft TRANSACTION Server. Emphasis on the "TRANSACTION". Anyone who thinks that MTS is the same thing as a J2EE App Server simply does not understand what MTS is for.

Anyone who thinks J2EE application servers do not support TRANSACTIONS does not know what J2EE application servers are for.

Please research what I have said before replying. MTS is an application server, Weblogic AS is an application server. They both have nearly the same functionality, only the underlying implementations differ.