Building a Sound Package Structure By Sonam Chauhan

---

The graphics supporting this article were generated using the webMethods Developer v4.6.

---

The Two-Minute Introduction to Integration Server Development

webMethods Developer is an innovative Java application development front-end for the webMethods Integration Server (IS) platform. Loosely based on the concept of an Integrated Development Environment (IDE), the webMethods Developer tool provides a powerful visual-programming methodology that greatly simplifies and speeds up IS development.

All work in the IS platform is done by services. Services are procedural units similar to a method or a function in other programming languages. To give IS developers a head start, webMethods provides a set of core utility services that implement the most common IS programming procedures. For example, the base IS server platform already contains services that parse and validate XML, carry out EDI translations, act as HTTP and FTP clients, etc. The webMethods visual programming methodology is named Flow.

Using a simple point-and-click interface, a Flow service can be built that invokes other services without writing a single line of code. Even better, experienced programmers can endlessly extend the IS platform by programming new behaviors in Java right from within the webMethods Developer. Java services are invoked in the same way that Flow services are. Services can also be coded in C or C++, but Flow services and Java services suffice for all but the most specialized of requirements.

---

Everything In Its Proper Place

Of course, with a typical IS server having hundreds of services, it is important to intuitively and consistently organize them for easy access by IS developers. This is where Packages and Folders come in. A package is a logical container for a set of services and related files. Folders are further logical sub-divisions under packages. To get a good idea of how Packages and folders are used, take a look at the WmPublic package in webMethods Developer. This package contains the base IS utility services supplied by webMethods.

Our task today is to to setup our own development workspace and organize our custom services. Let's begin by considering a few basic rules:

---

Rule 1: Don’t Touch The webMethods Packages!

Packages supplied by webMethods are easy to identify -- they start with "Wm" (e.g. WmPublic). No matter what the temptation, do not modify these packages -- instead create your own. If you modify a webMethods supplied package, not only can you easily damage something crucial for proper functioning of the server; doing this takes you right out of "Support Land". Of course, exceptions have sometimes to be made to this rule -- usually, for fixing a bug that webMethods are being exceptionally tardy about fixing themselves. Just be very careful and document everything"

---

Rule 2: Remember, "Folders Merge, Services Collide"

The slogan above is taught in just about all webMethods training courses. It refers to a rather confusing fact - that the package name plays no part in uniquely identifying a service. Rather, the Integration Server identifies services by the folders they are filed under and not the package name. For example, the Integration Server HTTP-client utility service is referred to as pub.client:http and not WmPublic.pub.client:http -- even though it resides in the WmPublic package.

Now, since services names must be unique, one can never do all three of the following -- even in different packages:

1. Create a top-level folder called "pub"
2. Create a subfolder underneath it called "client"
3. Put a service called "http" in client

With hundreds of services names to watch out for, this can become a tiresome thing to watch out for. Hence Rule 3:

---

Rule 3: Name Your First Subfolder Properly; Forget About Rule 2

This is a handy convention many webMethods developers use. Simply keep only one top-level folder directly underneath your custom package and name it the same name as the package. Some thought will soon make it apparent why Rule 2 is no longer a concern -- you’ve effectively prepended service names with the name of the package they exist in!

---

Rule 4: Balance Your Packages

While there is no one correct way of parceling your code out into packages, there are two opposing requirements you must balance:

1. Only put logically related services in the same package (i.e. Avoid large "Super-Packages" that are constantly modified for small changes)
2. Avoid a package explosion (i.e. Try making sure the number of packages is manageable).

---

[1]  2  Next>>

Go Deeper on the Subject: The wMUsers Discussion Forums