 | Level: Intermediate Bernhard Jakob, Software Engineer, IBM, Intel, Microsoft,HP
Stefan Ruettinger, Software Architect, IBM, Intel, Microsoft,HP
Frank Groezinger, Project Lead,
IBM
Gary Bist, Technical Writer, IBM Toronto Lab
07 Mar 2007 WebSphere Integration Developer 6.0.2 provides a new feature that lets you quickly and easily get services and XML files from the IBM® WebSphere® Service Registry and Repository The enterprise service discovery wizard, currently used with resource adapters to discover services on Enterprise Information Systems (EIS), can now also discover and retrieve artifacts in a Service Registry and Repository. This article describes how to use this wizard to bring your Service Registry and Repository artifacts into WebSphere Integration Developer v6.02.
Enterprise service discovery wizard for Service Registry and Repository
For several years developers have used the enterprise service discovery wizard in WebSphere Integration Developer to discover services on EIS systems. The wizard is a querying tool that discovers and retrieves business objects and interfaces. Version 6.02 extends this wizard to perform a similar function with the Websphere Service Registry and Repository (hereafter called Service Registry and Repository). If you’re working on service oriented architecture (SOA) applications, this tool provides a shortcut to discovering and retrieving the artifacts in a Service Registry and Repository.
As a refresher, let’s talk about what a Service Registry and Repository registry does and the artifacts it contains and manages. You should store all interfaces, business processes and XML artifacts created and used by SOA applications in a central, enterprise-wide repository. In this central repository, you can maintain endpoints, authorization, versioning and governance of the shared artifacts for the entire enterprise. Many enterprises now use theService Registry and Repository as their standard registry to contain and manage these artifacts.
You can find more information about the Service Registry and Repository in the article Introducing IBM WebSphere Service Registry and Repository.
How the enterprise service discovery wizard works
Let’s look conceptually at how the enterprise service discovery wizard works with the Service Registry and Repository to retrieve the artifacts needed by those developing SOA applications (Figure 1). The wizard presents a list of Service Registry and Repository registries that you can connect to. This list contains registries that have been preconfigured to access a specific Service Registry and Repository (a simple procedure that we’ll explain later in this article).
After connecting to the repository, a query page lets you discover the artifacts in the registry and then filter the list using queries. Since the list contains many artifacts, the filtering function lets you add precision to your searches. You can constrain the list to only certain types of files, such as interfaces (Web Services Description Language (WSDL) files) or business objects (XML schema definition (XSD) files), etc., or filter on the names of the files. In our example in Figure 1, the query looks for interfaces and business objects that are related to the subject of computer parts inventory.
The next stage selects the artifacts to import from the query. In our example, we defined XML files related to computer parts that are available for high and low end computers as the artifacts to import. Note that the wizard also identifies referenced files; for example, if you discovered the interface HighEndComputers, then the wizard identifies the related business objects, such as HighEndDiskDrive, HighEndMemory and HighEndProcessor.
The final stage is importing the artifacts. At import time, the enterprise service discovery wizard provides some practical options for developers who work regularly with these types of files. One useful option, for example, is to separate inline schemas from the interface files. We’ll discuss this option later in this article, but in a nutshell developers can work with files that other developers (who use inline schemas) have contributed to a Service Registry and Repository.
Figure 1. Using the enterprise service discovery wizard with a Service Registry and Repository
You can use the wizard to discover and retrieve any XML file in a Service Registry and Repository. The most common artifacts to discover and retrieve are:
- Interfaces
- Business objects
- Other XML structures
Since the Service Registry and Repository supports versioning of files, you can further limit these artifacts to a particular version.
Importing artifacts from aService Registry and Repository
Next we’ll explain the detailed steps to configure the wizard, get the files you want, and bring them into your workspace. We use our computer parts inventory sample as previously described.
Configuring and testing the connection to a Service Registry and Repository
Before you can access a Service Registry and Repository registry, you need to do some setup:
- In WebSphere Integration Developer, select Window and then Preferences from the menu. The Preferences window opens.
- Select WebSphere Service Registry and Repository. In the WebSphere Service Registry and Repository servers page, click the Add button to open the Add Service Registry window (Figure 2).
Figure 2. Configuring the enterprise service discovery wizard to access a Service Registry and Repository
- On this window you provide the registry’s URL and name. In many businesses, the URL is provided by a system administrator. You also need to provide a name for your registry, which can be whatever you like. This name will appear in the list of registries later when you want to connect to a Service Registry and Repository.
- If your organization does not require any security, then you can test your connection immediately and, if successful, your configuration is complete. However, if security is required, use the Connect to server with security option to specify the following security attributes:
- Userid and password to access the server with the Service Registry and Repository
- The location and password of the key store file containing the private key used in digital encryption
- The location and password of the trust store file containing the public key used in digital encryption
Discovering the artifacts in a Service Registry and Repository
Once configured, connecting to the registry is similar to using the enterprise service discovery wizard to access a back-end system with a resource adapter. If you are familiar with this popular wizard in WebSphere Integration Developer, then you do not need to learn a new tool.
To discover artifacts:
- Right-click the module name that will contain the imported artifacts. From the context menu, select Enterprise Service Discovery.
- The wizard opens with a list of the items that the wizard can be used with (Figure 3). Since this is the start of the enterprise service discover wizard which is also used with resource adapters, you will also see an Import Resource Adapter button. This button is not applicable to Service Registry and Repository. Select IBM WebSphere Service Registry and Repository.
Figure 3. Specifying that you want to use the wizard with a Service Registry and Repository
- On the next page, select the specific Service Registry and Repository that you want to access, which in our case is the Computer Inventory registry (Figure 4).
Figure 4. Specifying the exact registry
- After clicking Next, you will have connected to the Service Registry and Repository. The Find and Discover Enterprise Services page opens and you can look for the artifacts you want to import.
- If you click Execute Query, it retrieves ALL the interfaces in the Service Registry and Repository registry. They will appear in the Objects to be imported pane. Since there may be hundreds of interface files in the Service Registry and Repository, this approach is not the best use of the enterprise service discovery wizard.
- Our goal was to find the interfaces and business objects relevant to computer parts inventory. To add precision to the query, click Edit Query, which opens the Query Filter Properties page (Figure 5).
Figure 5. Using the query filter options to refine your query
- The File type field lets us constrain our search by type. We started with interfaces, so select Web services (WSDL). Since you know that the interface names contain the text Computer, add that term in the Search field. Selecting Name meant that any interface name containing the term Computer gets discovered. Other items to constrain searches include fields for the description and owner of the artifact. If you created a custom property to specify versions of files, then you could use the custom properties section to further constrain the search by version.
- You can now start to build the list of artifacts you want to import in the Find and Discover Enterprise Services page (Figure 6). For our example, clicking Execute Query (after creating the query for interfaces with the term Computer) finds HighEndComputers and LowEndComputers in the Objects discovered by query pane.
Figure 6. Building the list of files to be imported
- To display additional information associated with artifacts, select Details. In Figure 6, for example, you can see that the
OrderParts.bpel file is associated with the description Computer Inventory. With this information, you can return to the Query Filter Properties page using the Edit Query button and search for files using the term Computer Inventory in the Description field.
- Click Add to import list to move the items from the discovered state to the list of items to be imported. This step moves them into the Objects to be imported pane.
Referenced files
The enterprise service discovery wizard for a Service Registry and Repository is more than just a file retrieval tool. It automatically detects referenced files (Figure 7). For example, on adding the LowEndComputers.wsdl file, that is, an interface file, to the Objects to be imported list, the wizard detects that there are referenced XSD files, that is, business objects, and you are prompted to accept them (the default). In most cases, you would want to import the referenced files. Without this feature, you would need to find all the referenced files yourself manually, which would be a labor-intensive task.
Figure 7. Referenced files automatically identified by the wizard
When you have all the interfaces, business objects, and any other XML files you may need, click Next to get to the Generate Artifacts page (Figure 8). Since we began by selecting the module name ComputerInventory, it appears in the Module name field. You also have the option at this time of creating a new module for your artifacts.
Specifying a folder for your imported artifacts is a recommended good practice even though the logical view in the Business Integration navigation will hide it. Why? Modules contain many files. Organizing your files into folders will make it easier to find specific files that you need later in the development cycle. You can view your folders in the Physical Resources view.
Figure 8. Specifying the module for the artifacts and some options to perform at import time
Separating inline schemas
One difficulty when you retrieve services from other developers is that the services were created using different vendors’ tools. This means that even though a Service Registry and Repository conforms to the WSDL specification, it may vary from the format expected by the developer retrieving the file.
The most common variance is that some vendors’ tools place their schemas inline in a WSDL file (that is, their interfaces and business objects are put into one single file) and other vendors’ tools separate interfaces and business objects. WebSphere Integration Developer, for example, separates interfaces and business objects. When you import these objects, you can specify an option to separate interfaces and business that use an inline schema. Otherwise, you would need to split these files manually, a labor-intensive affair when importing dozens of files.
Separating interfaces and bindings
Another practical option is to separate the interface and binding into another file. This option is useful if you intend to use mediation or some other processing with the imported files, and want to refer to that work to from the same interface.
- Click Finish to import the files into your module.
Examining the retrieved artifacts in your workspace
The imported artifacts appear in the Business Integration navigation, categorized like other artifacts created in WebSphere Integration Developer (Figure 9); that is, business processes appear under Business Logic/Processes, business objects under Data Types and interfaces under Interfaces. Since the Business Integration view is a logical view, you do not see any file types or folders, which you can view using the Physical Resources view.
Figure 9. Retrieved artifacts from a Service Registry and Repository in WebSphere Integration Developer
In most cases, you need to revise the files you imported using the editors in WebSphere Integration Developer. For example, you might need to rename the namespaces in the files you imported to match the namespace you are using in your current application. You can use the refactoring function to rename the namespaces.
Conclusion
When you create services that reuse or extend similar services found in a Service Registry and Repository, you need to quickly and easily find and import the required XML files. In this article, you’ve learned how to use the enterprise service discovery wizard in WebSphere Integration Developer to solve this challenge. You’ve also learned about several features and options in this wizard that can significantly reduce the time to find the files you need and the time to revise the imported files to suit your current development environment.
Resources
About the authors | | | Bernhard Jakob is a software engineer at IBM’s Boeblingen Lab. He is team lead responsible for the development of the Service Registry and Repository discovery wizard as well as for the documentation generator and C discovery agent. You can reach Bernhard at BJAKOB@de.ibm.com. |
| | | Stefan Ruettinger is a software architect at IBM’s Boeblingen Lab. He works on the architecture and design of the Service Registry and Repository discovery wizard as well as on the business process editor, human task editor, relationship editor and other parts of WebSphere Integration Developer. You can reach Stefan at RUE@de.ibm.com. |
| | | Frank Groezinger works as the project lead for WebSphere Integration Developer development at IBM's Boeblingen Lab. He is responsible for the development of the business process editor, human task editor, documentation generator, Service Registry and Repository discovery wizard, relationship editor and other editors. You can reach Frank at GROEZING@de.ibm.com. |
| | | Gary Bist is a technical writer at IBM’s Toronto Lab. He has written documentation for several aspects of WebSphere Integration Developer including the enterprise service discovery wizard. Previously, we worked on the product’s predecessor, WebSphere Studio Application Developer Integration Edition. You can reach Gary at bist@ca.ibm.com |
Rate this page
| |
