What is Moniker?
A moniker is an object (or component ) in Microsoft’s Component Object Model ( COM ) that refers to a specific instance of another object. Monikers originated in Microsoft’s Object Linking and Embedding ( OLE ) technology as a means of linking objects.
A moniker may refer to any single object, or may be a composite made of a number of separate monikers, each of which refers to a particular instantiation of an object.
The moniker is sometimes referred to as an “intelligent name,” because it retains information about how to create, initialize , and bind to a single instance of an object. Once created, the moniker holds this information, as well as information about the object’s states in that specific instantiation.
Since COM is not language-specific, a moniker can be used with any programming language. The programmer gives the instantiation of the object a name. By calling the moniker in code, a programmer can refer to the same object with the same states.
If, for example, a moniker is created for a query , the programmer can reuse the query simply by calling the moniker in the code, because the moniker itself has the necessary information.
A few tips on deciding between EJB and COM
An article by Ed Roman, CEO of The Middleware Company
Recently, there’s been much said about Enterprise JavaBeans (EJB) and Microsoft’s COM+ technologies. Some assert that EJB is new, and is therefore not ready for prime-time. Others question the historical scalability of Windows, and are uneasy about using Windows 2000 in their mission-critical deployments. So what’s a development lead to do when deciding between these two environments?
In this article, I will raise some questions that you should be asking yourself to help you decide on the technology that’s right for your business. This article will not answer all of your questions, but it will get you asking the right ones.
ISV or IT Shop?
An important question to ask yourself is: are you in the business of selling software to other companies, or do you host the software yourself?
For most companies that are selling software to other businesses, EJB is usually the pick of the litter. Why? Because EJB supports a heterogeneous deployment environment. Unless you can guarantee that every one of your customers will accept a Windows solution, you are restricting your salespeople from major accounts that may have UNIX or mainframe-based solutions. This is rarely acceptable at most ISVs. If you don’t know what your customers are using, then talk to your sales force and your consultants, and have them find out for you. Don’t be shy — the more data you have, the better.
If you’re hosting software, then you control the deployment environment. That enables you to pick COM+ as well as EJB, and the playing ground is equal.
Existing developer skill-sets
What do your developers know today? Are they Java zealots, or C++ wizards? Do they have experience with MTS/COM+, EJB, or neither? This should certainly influence your purchase decision. After all, recruiting, hiring, training, and retaining employees is going to be your #1 problem, regardless of your industry. You can gain an immense amount of leverage by choosing a technology that is compatible with your developers’ skill-sets.
Embracing Java
Your choice of programming languages is absolutely critical to your choice of middleware. Why? Because EJB components must be written in Java, which requires a whole-hearted dedication to the Java programming language. If you are unwilling to commit to the Java programming language, then COM+ is a more attractive solution.
The opposite argument applies as well. If you are willing to bet on Java, then EJB is usually the best choice. If you recall, a recent court decision has undermined Microsoft’s control of the Java platform. Because of this, Microsoft is developing new programming languages, such as COOL. While they may officially support Java, there are strong indications that they will have Java and Visual J++ on maintenance mode. If you want faith that your vendor will continue to strongly support the Java programming language, then EJB (and CORBA) are the least risky choices.
Features in the underlying middleware
Most comparisons of EJB and COM+ focus on a feature-for-feature comparison of the two platforms. These are all important differences, and you should weight each of these features as they apply to your business problem when making your architectural decision.
You should note, however, that real, successful E-Commerce systems are being developed today to both EJB and COM+. Despite the lack of support for certain features in each platform, today’s development teams have learned to cope with some of the limitations of their chosen platform, such as lack of persistent components in COM+, or lack of queued components in EJB. It is very rare that an architectural decision will be made soley on the basis of features, as the two architectures are very, very similar. Rather, the overwhelming business forces at play are much greater factors.
Cost of systems
One great feature of Microsoft technology is they always seem to undercut the competition when it comes to price. Windows 2000 is no exception. There is a remarkably low cost per transaction in Windows 2000, and this stems from the volume pricing Microsoft employs. Furthermore, the COM+ subsystem ships with Windows 2000, whereas EJB-based application servers are sold separately from the underlying platform. When you couple low-cost Intel hardware with a Microsoft-based middleware solution, the cost per transaction is remarkably low.
The reader should note, however, that the cost of the underlying middleware, operating system, and hardware is always dwarfed by the total cost of ownership of a project. When you consider the cost of hiring, training, and retaining developers, the cost of developing and maintaining the solution, the potential lost business due to wrong architectural decisions, and the inertia of your decision over the years to come, the cost of the software and hardware are minimal.
Purchasing components vs. writing from scratch
One value of EJB and COM+ is they enable ISVs to ship applications as components. In the future, this will enable E-Commerce applications to be assembled in a piecemeal fashion from components specialized to their vertical market. This paradigm is much more appealing than writing applications from scratch, and is also superior to purchasing a proprietary, out-of-the-box commerce site that is not customizable. If new components are needed, the customer can craft their own, custom components as well.
Today, there aren’t a whole lot of off-the-shelf server side components available. If, however, you do find a vendor with components in your vertical industry, then that becomes a compelling reason to choose their underlying supported middleware. A few web sites you may want to check for components include:
http://www.flashline.com
http://www.componentsource.com
Summary
In summary, the decision between EJB and COM+ is a tough one, and this article is only meant to whet your appetite for the issues at hand. Chart 1 summarizes the differences between the two platforms.
|
Feature |
EJB |
COM+ |
|
Component Language |
Java only |
All (Java: unclear future) |
|
Platforms |
All |
Windows 2000 |
|
Middleware Vendors |
30+ |
Microsoft |
|
Legacy Integration |
RMI/JNI, CORBA, Connectors (future) |
COM TI, MSMQ, OLE DB |
|
Protocol |
Any (future: IIOP) |
DCOM |
|
Stateless components |
Yes |
Yes |
|
Stateful components |
Yes |
No |
|
Persistent components |
Yes |
No |
|
Method-granularity transactions |
Yes |
No |
|
Middle-tier load balancing |
Most vendors |
Coming soon |
|
Middle-tier data caching |
Some vendors |
No |
|
Queued components |
No |
Yes |
|
Single-vendor solution |
No |
Yes |
|
Low cost per transaction |
No |
Yes |
|
Middleware comes with OS |
No |
Yes |
|
Per-machine processors |
256+ |
16 (32 via OEMs) |
|
Cluster-wide processors |
Theoretically unlimited |
Theoretically unlimited |
|
Development tools |
Choice of many |
Microsoft Dev Studio |
If you want more information about how these technologies compare, check out a transcript from a debate I recently held with Roger Sessions (a COM+ evangelist) located at http://www.middleware-company.com/debate.html. For fellow technologists, if you want more information about how this middleware compares at a technical level, see my comparison whitepaper at TheServerSide.com resources section .
But in the end, remember this: both EJB and COM+ will be successful. This is not a zero-sum game, and there is no clear-cut winner at this point. Both will have their markets, and both are backed by strong, proven industry leaders. For those of you who wish to reduce your projects’ risk levels when deciding between EJB and COM+, my advice is to make a judgment call, and then prototype a first-pass solution to test the viability of your chosen platform. Only then will you know if your chosen middleware meets your specific business needs.
Component Requirements
|
Component Requirements |
|
The advantage of using components result directly from their ability to dynamically plug into and unplug from an application. In order to achieve this capability , components must meet two requirements. 1. Components must link dynamically 2. Components must hide (or encapsulate) the details of how they were implemented. 1. Dynamic Linking · The ultimate goal of this is to have an end user replace components in an application while that application is running. · Support for changing components at run time requires the ability of dynamically link components together. · In distributed environment there is no assurance that the component will be idle for modification. So, components should have facility to update or replace them while it is used by other system in the network. 2. Encapsulation · A program or a component that uses another component is called the client. A client is connected to a component through an interface. · If the component changes without changing the interface, the client doesn’t have to change. Similarly, if the client changes without changing the interface, the component doesn’t have to change. · However, if changing either the component or the client changes the interface, the other side of the interface must also change. · Therefore, to take advantage of dynamic linking, components and clients must strive not to change their interfaces. They must be encapsulated. · The more the interface is isolated from implementation details, the less likely the interface will change as a result of changing the client or the component. · If the interface doesn’t change, changing a component will have little effect on the rest of the application. Isolating the client from the component’s implementation puts some important constraints on the component. The following is a list of these constraints. 1. The component must hide the computer language used for its implementation. Exposing the implementation language creates new dependencies between the client and the component. 2. Components must be shipped in a binary form. If components are to hide their implementation language, they must be shipped already compiled, linked and ready to use. 3. Components must be upgradable without breaking existing users. New versions of a component should work with both old and new clients. 4. Components must be transparently relocatable on a network. A component and the program that uses it should be able to run in the same process, in different processes, or on different machines. The client should be able to treat a remote component the same way it treats a local component. |
COM : Fundamentals
COM
- COM is a specification
- It specifies how to build components that can be dynamically interchanged.
- COM provides the standard that components and clients follow to ensure that they can operate together.
- The COM specification is a document that sets the standard for the component architecture.
What are COM Components?
- COM component consists of executable code distributed either as Win32 dynamic link libraries (DLLs) or as executables (EXEs).
- Components written to the COM standard meet all requirements for component architecture.
- COM components link dynamically using DLLs.
- COM components can be encapsulated easily because:
o COM components are fully language independent. They can be developed using almost any procedural language Ada to C to Java to Modula-3 to Oberon to Pascal.
o Any language can be modified to use COM components, including Smalltalk and Visual Basic.
o COM components can be shipped in binary form.
o COM components can be upgraded without breaking old clients. Because it provides a standard way to implement different versions of a component.
o COM components can be transparently relocated on a network. A component on a remote system is treated the same as a component on the local system.
- COM components announce their existence in a standard way. Using COM’s publication scheme, clients can dynamically find the components they need to use.
- COM components are a great way to provide object-oriented APIs or services to other applications.
- COM components are also great for building language-independent component libraries from which applications can be rapidly built.
COM is not…
- COM is not a computer language.
- COM does not compete with computer languages.
- COM tells how to write components.
- COM also does not compete with or replace DLLs.
- COM uses DLLs to provide components with the ability to dynamically link.
- COM is not primarily an API or a set of functions like the Win32 API.
- COM does not provide services such as MoveWindow or the like.
- COM is not a C++ class library like the Microsoft Foundation Classes (MFC).
- COM provides a way to develop language-independent component libraries, but COM does not provide any implementation.
The COM Library
- COM has an API, the COM library, which provides component management services that are useful for all clients and components.
- Most of the functions in the API are not too difficult to implement when developing COM-style components on a non-Windows system.
- The COM library was written to guarantee that the most important operations are done in the same way for all components.
- The COM library also saves developers time implementing their own components and clients.
- Most of the code in the COM library is support for distributed or networked components.
- The Distributed COM (DCOM) implementation on Windows System provides the code needed to communicate with components over a network.
- This reduces to write the networking code.
COM and CORBA Side by Side
.
|
Trait |
Similarities |
Differences |
|
Interfaces |
Each uses their own IDL to describe interfaces. |
CORBA IDL is simpler an elegant than COM IDL COM has better tool support for creating and managing IDL than CORBA |
|
Datatypes |
Both support a rich set of data types Both also support constants, enumerated types, structures and arrays. |
COM has automation types. Automation compatible interfaces are supported in more client environments than non-compatible interfaces. Because the non-compatible interfaces are not guaranteed to work other than C++. Any CORBA interface can be used from any CORBA client |
|
Proxies, Stubs & Skeletons |
COM and CORBA rely on client stubs and server stubs to handle remoting issues. COM & CORBA generate client stubs and server stubs from IDL. |
COM client & server stubs are called as Proxy & Stub and in CORBA called as Stub & Skeleton. COM proxy-stub DLLs are used by all language environments. In CORBA, a separate stub-skeleton must be generated for each ORB/language combination. |
|
Marshaling & Unmarshaling |
COM and CORBA handle marshaling in client stubs and server stubs. Users do not need to worry about marshaling. |
COM allows automation-compatible interfaces to use type library marshaling, thus eliminating the need for customized stubs. |
|
Object Handles |
COM & CORBA support reference counted handles on object instances. |
COM calls object handles as interface pointers and CORBA calls as object references. CORBA supports multiple inheritance in the interface hierarchy. COM supports single inheritance only; however a COM object supports more than one distinct interface. |
|
Object Creation |
Both use factories to create objects instances. |
COM has a standard factory interface called IClassFactory CORBA factories are customized persistent CORBA objects. |
|
Object Invocation |
Both allow for method invocation similar to native environment method invocation. |
COM’s error-handling mechanism is based on HRESULT return values. CORBA supports user-defined exception types in IDL. |
|
Object Destruction |
COM and CORBA rely on reference counting to determine when an object can be destroyed |
COM supports distributed reference counting and garbage collection. CORBA reference counts are maintained separately in the client and server. |
DCOM Vs CORBA
|
Differences |
DCOM |
CORBA |
|
Focus |
Desktop first; enterprise second |
Enterprise first; desktop second |
|
Platforms |
Windows NT; support for Windows (all), Macintosh, UNIX, MVA |
MVS, UNIX, Windows (all), Macintosh |
|
Availability |
Single vendor; availability from other vendors expected |
Multi-vendor |
|
Service differences |
ActiveX-interactive content standard |
Significant number of additional services, including query, trader, transactions, as well as facilities in the areas of information management and system management. Lastly, services in areas such as finance, distributed simulation, and computer integrated manufacturing |
|
Maturity |
NT shipped in 1996; decade-long evolution of OLE and COM products; most services and facilities under construction |
Products since 1992; many services and facilities under construction |
|
Language Binding |
C, C++; working on JAVA, Visual Basic, Ada |
C++, Smalltalk, Ada95; JAVA and COBOL |
|
Interface Inheritance |
Supports aggregation but not inheritance; interfaces are not classes. |
Multiple Inheritance; interfaces are classes. |
Similarities between DCOM and CORBA
|
Similarities |
DCOM |
CORBA |
|
Object Model |
Yes |
Yes |
|
Standards body |
Recently made formal; managed by the Active Group, an Open Group affiliate |
Formal: managed by the Object Management Group |
|
Interface similarities |
Microsoft IDL allows for specification of interface and implementation and provides a repository for storage of interfaces. |
CORBA IDL allows for separation of interface and implementation and provides a repository for storage of interfaces. |
|
Language independence |
Yes |
Yes |
|
Compound document model |
Yes-OLE |
Yes-OpenDoc |
|
Location Transparency |
Yes |
Yes |