Java Reference
In-Depth Information
<configuration>
<glassfishHome>${my.glassfish.home}</glassfishHome>
</configuration>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>redeploy</goal>
</goals>
</execution>
</executions>
</plugin>
This plug-in executes during the install phase to deploy your WAR or EAR automatically dur-
ing your build. This is a nice convenience. The only item of note here is that it's important to
use a property for things like paths that might be specific to a given developer's box. Here,
I'm referencing a property whose value is specified in my own settings.xmlfile.
Creating the client project
If you are creating a service for public consumption, you may just stop at creating the service
itself, and let clients figure out on their own how to use it. But you might want to also create
a client JAR that you can make available to users on a Java platform, as a convenience. This
is something that Amazon, eBay, Google, and others did in the early days of web services, to
make their services easier to work with. They'd distribute a client ZIP file that contained both
Java and C# code, allowing developers to get up and running with their services more quickly.
Even if you are developing web services for internal use only, it still may be a good idea to cre-
ate a client JAR that already contains the generated artifacts off the WSDL so that integrating
usage of your service into business applications is not only easier, but also more controlled.
For example, if you're creating the client JAR, you can add features such as WS-Addressing,
schema validation, and so on without requiring every developer in your shop to understand all
those things, or even to be aware that they're happening under the hood. This allows you more
flexibility. Of course, if you have business applications written in COBOL or C# that need to
invoke your service, they can't use your Java client. You can then either create one for them,
or let them do it themselves.
