The enterprise service discovery wizard provides options for you. This section examines the meaning of choosing certain options and guidance in the use of the wizard.
When using the enterprise service discovery wizard on PeopleSoft and similar ERP and database type systems, the wizard will detect the connection properties and towards the end of building your import or export component, you can use these properties or you can specify your own. Using the connection properties specified on a server means that someone, usually a system administrator, has set up the connection properties ahead of time. The system administrator provides you with the Java™ Naming and Directory Interface (JNDI) lookup name and Java Authentication and Authorization Service (JAAS) alias name. You insert the information and continue using the wizard. The advantage to this method is that you and others do not waste your development time in this area, security is maintained by one person, the system administrator, and there is one central control area to maintain. However, you may not have such a person, particularly if you are in a smaller organization, or you do not have many servers to maintain. In this case, the enterprise service discovery wizard provides you with the connection information it has found and you need to only add a few extra values. For example, the resource adapter you use might require that you add the password and national language information.
When using the enterprise service discovery wizard on CICS® and IMS™ systems, you can either specify a JNDI name on the server where the connection information has been set up previously or you can specify the connection information as you create your import component. As discussed in the previous section, using the connection properties specified on a server means that someone, usually a system administrator, has set up the connection properties ahead of time. The system administrator provides you with the JNDI lookup name and JAAS alias name. You insert the information and continue using the wizard. The advantage to this method is that you and others do not waste your development time in this area, security is maintained by one person, the system administrator, and there is one central control area to maintain. However, not everyone has the need for a system administrator especially if you are working in a small organization or one that has only a few servers. In this case, you can specify them at the time you create the import component. In the case of a CICS server, for example, the values you would need to know include the gateway, the server, and userid and password.
When you build a component using the enterprise service discovery wizard, you are given the option of including the resource adapter in your module. Why might you consider this option and what is the tradeoff? Sometimes you may have several versions of the same resource adapter. Including the resource adapter with the module could be a way of handling the different versions. There is also a security consideration. You may not want a user accessing a resource adapter and so you could contain it in the module. Is the user accessing the resource adapter from the same application? Then you might include it. But if the user is accessing the resource adapter from another application, then it needs to be separate from the module.
The tradeoff for including the resource adapter in the module is that with each deployed service you are carrying the cost of an additional resource adapter, which can occupy considerable space on your application server. Also, there is a higher maintenance cost. When you have to upgrade a resource adapter, if it is installed on a server then you only have to make a single update. One more point: some resource adapters may only support being deployed embedded in a module or on the server.
A federated namespace is a logical namespace where elements of the logical namespace may reside in other places. Federated namespaces are supported in WebSphere® Integration Developer. Generally, federated namespaces will not pose a problem to you, however, you must be careful that you do not have collisions of types within a single namespace you have specified.
It is good practice to group the import and export components for a single EIS system. For example, you should not mix components created from querying a PeopleSoft server with components created from querying a CICS server. If you have different PeopleSoft systems referred to in the same module, the components should be grouped accordingly.