Distributed business objects, if they are to be effective, require the same system-level management from CTMs as business data requires from relational databases. System- level functionality like concurrency, transaction management, and resource management is necessary if the business system is going to be used for large user populations or mis- sion-critical work. It is unrealistic and wasteful to expect application developers to rei vent this system-level functionality when commercial solutions already exist CTMs are to business objects what relational databases are to data. CTMs handle all the system-level functionality, allowing the application developer to focus on the business problems. With a CTM, application developers can focus on the design and development of the business objects without having to waste thousands of hours developing the infra- structure that the business objects operate in EJB 2.0: Asynchronous Messaging An asynchronous messaging system allows two or more applications to exchange information in the form of messages. A message, in this case, is a self-contained package of business data and network routing headers. The business data contained in a message can be anything-depending on the business scenario-and usually contains information about some business transaction. In enterprise messaging systems, messages inform an application of some event or occurrence in another system Messages are transmitted from one application to another on a network using message oriented middleware(MOM). MOM products ensure that messages are properly distributed among applications. In addition, MOMs usually provide fault tolerance, load balancing, scalability, and transactional support for enterprises that need to reliably exchange large quantities of messages MOM vendors use different message formats and network protocols for exchanging messages, but the basic semantics are the same. An API is used to create a message, give it a payload(application data), assign it routing information, and then send the message The same API is used to receive messages produced by other applications In all modern enterprise messaging systems, applications exchange messages through virtual channels called destinations. When sending a message, it's addressed to a destination, not a specific application. Any application that subscribes or registers an interest in that destination may receive that message. In this way, the applications that receive messages and those that send messages are decoupled. Senders and receivers are not bound to each other in any way and may send and receive messages as they see fit Copyright(c)2001 OReilly Associates
DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates Distributed business objects, if they are to be effective, require the same system-level management from CTMs as business data requires from relational databases. Systemlevel functionality like concurrency, transaction management, and resource management is necessary if the business system is going to be used for large user populations or mission-critical work. It is unrealistic and wasteful to expect application developers to reinvent this system-level functionality when commercial solutions already exist. CTMs are to business objects what relational databases are to data. CTMs handle all the system-level functionality, allowing the application developer to focus on the business problems. With a CTM, application developers can focus on the design and development of the business objects without having to waste thousands of hours developing the infrastructure that the business objects operate in. EJB 2.0: Asynchronous Messaging An asynchronous messaging system allows two or more applications to exchange information in the form of messages. A message, in this case, is a self-contained package of business data and network routing headers. The business data contained in a message can be anything—depending on the business scenario—and usually contains information about some business transaction. In enterprise messaging systems, messages inform an application of some event or occurrence in another system. Messages are transmitted from one application to another on a network using messageoriented middleware (MOM). MOM products ensure that messages are properly distributed among applications. In addition, MOMs usually provide fault tolerance, load balancing, scalability, and transactional support for enterprises that need to reliably exchange large quantities of messages. MOM vendors use different message formats and network protocols for exchanging messages, but the basic semantics are the same. An API is used to create a message, give it a payload (application data), assign it routing information, and then send the message. The same API is used to receive messages produced by other applications. In all modern enterprise messaging systems, applications exchange messages through virtual channels called destinations. When sending a message, it's addressed to a destination, not a specific application. Any application that subscribes or registers an interest in that destination may receive that message. In this way, the applications that receive messages and those that send messages are decoupled. Senders and receivers are not bound to each other in any way and may send and receive messages as they see fit
Java Message service Each MOM vendor implements its own networking protocols, routing, and administration facilities, but the basic semantics of the developer API provided by different MOMs are the same It's this similarity in APls that makes the Java Message Service possible The Java Message Service(JMS)is a vendor-agnostic Java API that can be used with many different MOM vendors. JMS is very similar to JDBC in that application developer reuses the same API to access many different systems. If a vendor provides a compliant service provider for JMS, then the JMS API can be used to send eive messages to that vendor. For example, you can use the same JMS API to send messages us Progress'SonicMQ as you do IBMs MQseries Message-Driven beans All JMS vendors provide application developers with the same API for sending and receiving messages, and sometimes they provide a component model routers that can receive and send messages. These component models, however, are proprietary and not portable across MOM vendors Enterprise JavaBeans 2.0 introduces a new kind of component, called a message-driven bean, which is a kind of standard JMS bean. It can receive and send asynchronous JMS messages, because it's co-located with other kinds of rMi beans(entity and session beans)it can also interact with RMI components Message-driven beans in EJB 2.0 act as an integration point for a EJB application. plications to asynchronous messages which can be captured and processed by an EJB application. This is an extremely important feature that will allow EJB applications to better integrate with legacy and other proprietary systems Message-driven beans are also transactional and required all the infrastructure associated with other RMI based transactional server-side components. Like other RMI based components, message-driven beans are considered business objects, which full fill an important role of routing and interpreting requests and coordinating the application of those requests against other RMI based components, namely enterprise beans. Message driven beans are a good fit for the component transaction manager landscape and are an excellent addition to the Enterprise JavaBeans platform Copyright(c)2001 OReilly Associates
DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates Java Message Service Each MOM vendor implements its own networking protocols, routing, and administration facilities, but the basic semantics of the developer API provided by different MOMs are the same. It's this similarity in APIs that makes the Java Message Service possible. The Java Message Service (JMS) is a vendor-agnostic Java API that can be used with many different MOM vendors. JMS is very similar to JDBC in that application developer reuses the same API to access many different systems. If a vendor provides a compliant service provider for JMS, then the JMS API can be used to send and receive messages to that vendor. For example, you can use the same JMS API to send messages using Progress’ SonicMQ as you do IBM’s MQSeries. Message-Driven Beans All JMS vendors provide application developers with the same API for sending and receiving messages, and sometimes they provide a component model for developing routers that can receive and send messages. These component models, however, are proprietary and not portable across MOM vendors. Enterprise JavaBeans 2.0 introduces a new kind of component, called a message-driven bean, which is a kind of standard JMS bean. It can receive and send asynchronous JMS messages, because it’s co-located with other kinds of RMI beans (entity and session beans) it can also interact with RMI components. Message-driven beans in EJB 2.0 act as an integration point for a EJB application, allowing other applications to asynchronous messages which can be captured and processed by an EJB application. This is an extremely important feature that will allow EJB applications to better integrate with legacy and other proprietary systems. Message-driven beans are also transactional and required all the infrastructure associated with other RMI based transactional server-side components. Like other RMI based components, message-driven beans are considered business objects, which full fill an important role of routing and interpreting requests and coordinating the application of those requests against other RMI based components, namely enterprise beans. Messagedriven beans are a good fit for the component transaction manager landscape and are an excellent addition to the Enterprise JavaBeans platform
CTMS and Server-Side Component Models CTMs require that business objects adhere to the server-side component model imple mented by the vendor. A good component model is critical to the success of a develop ment project because it defines how easily an application developer can write business objects for the CTM. The component model is a contract that defines the responsibilities of the CTM and the business objects with a good component model, a developer knows what to expect from the CTM and the Ctm understands how to manage the business object. Server-side component models are great at describing the responsibilities of the application developer and CTM vendor Server-side component models are based on a specification. As long as the component adheres to the specification, it can be used by the Ctm. The relationship between the server-side component and the Ctm is like the relationship between a CD-ROM and a CD player. As long as the component(CD-ROM) adheres to the players specifications, you can play it A CTMs relationship with its component model is also similar to the relationship the viding alternate routes for load balancing, multiple tracks for concurrency, and a traff railway system has with trains. The rail way system manages the trains environment, pro control system for managing resources. The rail way provides the infrastructure that trains run on. Similarly, a CTM provides server-side components with the entire infrastructure needed to support concurrency, transactions, load balancing, etc Trains on the railway are like server-side components they all perform different tasks but they do so using the same basic design. The train, like a server-side component, focuses on performing a task, such as moving cars, not managing the environment. For the engi- neer, the person driving the train, the interface for controlling the train is fairly simple: a brake and throttle. For the application developer, the interface to the server-side compo- nent is similarly limited Different CTMs may implement different component models, just as different railways have different kinds of trains. The differences between the component models vary, like railway systems having different track widths and different controls, but the fundamental operations of CTMs are the same. They all ensure that business objects are managed so that they can support large populations of users in mission-critical situations. This means that resources, concurrency, transactions, security, persistence, load balancing, and distribution of objects can be handled automatically, limiting the application developer to a simple interface. This allows the application developer to focus on the business logic instead of the enterprise infrastructure Copyright(c)2001 OReilly Associates
DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates CTMs and Server-Side Component Models CTMs require that business objects adhere to the server-side component model implemented by the vendor. A good component model is critical to the success of a development project because it defines how easily an application developer can write business objects for the CTM. The component model is a contract that defines the responsibilities of the CTM and the business objects. With a good component model, a developer knows what to expect from the CTM and the CTM understands how to manage the business object. Server-side component models are great at describing the responsibilities of the application developer and CTM vendor. Server-side component models are based on a specification. As long as the component adheres to the specification, it can be used by the CTM. The relationship between the server-side component and the CTM is like the relationship between a CD-ROM and a CD player. As long as the component (CD-ROM) adheres to the player’s specifications, you can play it. A CTM’s relationship with its component model is also similar to the relationship the railway system has with trains. The railway system manages the train’s environment, providing alternate routes for load balancing, multiple tracks for concurrency, and a traffic control system for managing resources. The railway provides the infrastructure that trains run on. Similarly, a CTM provides server-side components with the entire infrastructure needed to support concurrency, transactions, load balancing, etc. Trains on the railway are like server-side components: they all perform different tasks but they do so using the same basic design. The train, like a server-side component, focuses on performing a task, such as moving cars, not managing the environment. For the engineer, the person driving the train, the interface for controlling the train is fairly simple: a brake and throttle. For the application developer, the interface to the server-side component is similarly limited. Different CTMs may implement different component models, just as different railways have different kinds of trains. The differences between the component models vary, like railway systems having different track widths and different controls, but the fundamental operations of CTMs are the same. They all ensure that business objects are managed so that they can support large populations of users in mission-critical situations. This means that resources, concurrency, transactions, security, persistence, load balancing, and distribution of objects can be handled automatically, limiting the application developer to a simple interface. This allows the application developer to focus on the business logic instead of the enterprise infrastructure
Microsoft's. net framework Microsoft was the first vendor to ship a CTM. Originally called the Microsoft Transaction Server(MTS), it was later renamed COM+ Microsofts COM+ is based on the Component Object Model(COM), originally designed for use on the desktop but eventually pressed nto service as a server-side component model For distributed access, COM+ clients use DCOM(Distributed Component Object Model) When Mrs was introduced in was exciting because it provided a very comprehensive environment for bu objects. With MTS, application developers ould write COM components without worrying about system-level concerns. Once a business object was designed to conform to the COM model, MTS(and now COM+) would take care of everything else, including transaction management, concurrency, resource management--everything Recently, COM+ has become part of Microsofts new NET Framework. The core functionality provided by COM+ services remains essentially the same in. NET, but the ay it's appears to a developer changes significantly. Rather than writing components as COM objects, applications written for the NET Framework are built as managed objects All managed objects, and in fact all code written for the NET Framework, depends on a Common Language Runtime(CLR). For Java-oriented developers, the CLr is much like a Java VM, and a managed object is very analogous to an instance of a Java class, i.e., to a Java object Although NET Framework provides many interesting features, as an open standard, it falls short. The COM+ services in the. NET Framework are Microsofts proprietary CTM which means that using this technology binds you to the microsoft platform. This may not be so bad, because NET promises to work well, and the microsoft platform is pervasive. In addition, the. NET Frameworks support for SOAP(Simple Object Access Protocol)will enable business objects in the. NET world to communicate with objects on any other platform written in any language. This can potentially make business objects in NET universally accessible, a feature that is not easily dismissed If, however, your company is expected to deploy server-side components on a non- Microsoft platform, NET is not a viable solution. In addition, the COM+ services in the NET Framework are focused on stateless components; theres no built-in support for persistent transactional objects. Although stateless components can offer higher performance, business systems need the kind of flexibility offered by CTMs that include stateful and persistent components Copyright(c)2001 OReilly Associates
DRAFT 10/21/0107/06/01 Copyright (c) 2001 O'Reilly & Associates Microsoft’s .NET Framework Microsoft was the first vendor to ship a CTM. Originally called the Microsoft Transaction Server (MTS), it was later renamed COM+. Microsoft’s COM+ is based on the Component Object Model (COM), originally designed for use on the desktop but eventually pressed into service as a server-side component model. For distributed access, COM+ clients use DCOM (Distributed Component Object Model). When MTS was introduced in 1996, it was exciting because it provided a very comprehensive environment for business objects. With MTS, application developers could write COM components without worrying about system-level concerns. Once a business object was designed to conform to the COM model, MTS (and now COM+) would take care of everything else, including transaction management, concurrency, resource management—everything! Recently, COM+ has become part of Microsoft’s new .NET Framework. The core functionality provided by COM+ services remains essentially the same in .NET, but the way it’s appears to a developer changes significantly. Rather than writing components as COM objects, applications written for the .NET Framework are built as managed objects. All managed objects, and in fact all code written for the .NET Framework, depends on a Common Language Runtime (CLR). For Java-oriented developers, the CLR is much like a Java VM, and a managed object is very analogous to an instance of a Java class, i.e., to a Java object. Although .NET Framework provides many interesting features, as an open standard, it falls short. The COM+ services in the .NET Framework are Microsoft’s proprietary CTM, which means that using this technology binds you to the Microsoft platform. This may not be so bad, because .NET promises to work well, and the Microsoft platform is pervasive. In addition, the .NET Framework’s support for SOAP (Simple Object Access Protocol) will enable business objects in the .NET world to communicate with objects on any other platform written in any language. This can potentially make business objects in .NET universally accessible, a feature that is not easily dismissed. If, however, your company is expected to deploy server-side components on a nonMicrosoft platform, .NET is not a viable solution. In addition, the COM+ services in the .NET Framework are focused on stateless components; there’s no built-in support for persistent transactional objects. Although stateless components can offer higher performance, business systems need the kind of flexibility offered by CTMs that include stateful and persistent components
EJB and CORBA CTMs Until the fall of 1997, non-Microsoft CTMs were pretty much nonexistent Promising products from IBM, BEA, and Hitachi were on the drawing board while MTs was already on the market. Although the non-MTS designs were only designs, they all had one thing in common: they all used CORBa as a distributed lost non-Microsoft CTMs were focused on. what was at the the more open standard of CORBA so that they could be deployed on non-Microsoft orms latform independent, So CORBA CTM vendors could provide their customers ith more implementation options. The problem with CORBA CTM designs was that they all had different server-side component models. In other words, if you developed a component for one vendor's CtM, you couldnt turn around an use that same component in another vendor's CTm. The component models were too different With Microsofts MTS far in the lead by 1997(it had already been around a year), CORBA-based CTM vendors needed a competitive advantage. One problem CTMs faced was a fragmented CORBA market where each vendors product was different from the next. A fragmented market wouldnt benefit anyone, so the CORBA CTM vendors needed a standard to rally around Besides the COrBa protocol, the most obvious standard needed was omponent model, which would allow clients and third-party vendors to develop eir business objects to one specification that would work in any CORBA CTM Microsoft was, of course, pushing their component model as a standard-which was attractive because MTs was an actual working product-but Microsoft didnt support CORBA. The OMG(Object Management Group), the same people who developed the CORBA standard, were defining a server-side component model. This held promise because it was sure to be tailored to CORBA, but the OMG was slow in developing a standard--at least too slow for the evolving CTM market s Recently, the introduction of SOAP(Simple Object Access Protocol)brings into uestion the future of the CORBa nlOP protocol (Internet-InterOperability Protocol) It's obvious that these two protocols are competing to become the standard language- dependent protocol for distributed computing. noP has been around for several years and is therefore far more mature, but as a late entry SOAP may quickly catch up by leveraging lessons learned in the development of llOP, released and called CCM. for CORBA Component Model. It has seen lackluster acceptance is general, and was forced to adopt Enterprise Java Beans as part of its component model just to be viable and
DRAFT, 10/21/017/6/20016/9/2001 21 EJB and CORBA CTMs Until the fall of 1997, non-Microsoft CTMs were pretty much nonexistent. Promising products from IBM, BEA, and Hitachi were on the drawing board, while MTS was already on the market. Although the non-MTS designs were only designs, they all had one thing in common: they all used CORBA as a distributed object service. Most non-Microsoft CTMs were focused on, what was at the time, the more open standard of CORBA so that they could be deployed on non-Microsoft platforms and support non-Microsoft clients. CORBA is both language and platform independent, so CORBA CTM vendors could provide their customers with more implementation options5 . The problem with CORBA CTM designs was that they all had different server-side component models. In other words, if you developed a component for one vendor’s CTM, you couldn’t turn around and use that same component in another vendor’s CTM. The component models were too different. With Microsoft’s MTS far in the lead by 1997 (it had already been around a year), CORBA-based CTM vendors needed a competitive advantage. One problem CTMs faced was a fragmented CORBA market where each vendor’s product was different from the next. A fragmented market wouldn’t benefit anyone, so the CORBA CTM vendors needed a standard to rally around. Besides the CORBA protocol, the most obvious standard needed was a component model, which would allow clients and third-party vendors to develop their business objects to one specification that would work in any CORBA CTM. Microsoft was, of course, pushing their component model as a standard—which was attractive because MTS was an actual working product—but Microsoft didn’t support CORBA. The OMG (Object Management Group), the same people who developed the CORBA standard, were defining a server-side component model. This held promise because it was sure to be tailored to CORBA, but the OMG was slow in developing a standard—at least too slow for the evolving CTM market6 . 5 Recently, the introduction of SOAP (Simple Object Access Protocol) brings into question the future of the CORBA IIOP protocol (Internet-InterOperability Protocol). It’s obvious that these two protocols are competing to become the standard languageindependent protocol for distributed computing. IIOP has been around for several years and is therefore far more mature, but as a late entry SOAP may quickly catch up by leveraging lessons learned in the development of IIOP. 6 Eventually, CORBA’s CTM component model was released and called CCM, for CORBA Component Model. It has seen lackluster acceptance is general, and was forced to adopt Enterprise JavaBeans as part of its component model just to be viable and interesting