By switching to the Service Interface page, we can see that it has automatically created a new operation on the interface for us (this can be avoided in a number of ways, if you write a method you don't want exposed):

Now, what if we want to have the Java service invoke the Database service? To provide a counterpoint, we'll do this from the Service Interface page. Simply drag the desired service's operation from the Service Explorer onto the operation in the Java service you want to do the invoking and the invocation is automatically created:

Switching to the source code, we can see that the code to invoke the sp_customer_list operation has been written for us, ready for us to start coding up what we want to do with the input and output parameters:

While this is a fairly nonsensical example of invoking another service, notice how a proxy for invoking the database service, MyASADatabaseServiceProxy, has been automatically created, so all we have to do is pass in the right arguments. The contents of the proxy are unimportant to us; it's just the interface (i.e., the static methods on the proxy) that we need to deal with.

Because I don't feel comfortable without discussing some level of technical detail, I'm going to delve briefly into the complexity of the service invocation above. Most service invocations are going to be simple, e.g., MyCalculatorServiceProxy.sqrt(289.0) but in this case, I chose a fairly complex service to invoke, specifically one that has in/out parameters. This means that, in the interface (WSDL), the service describes a number of parameters that are passed in, potentially modified, and then returned to the user. The way this has historically been supported is by using holders (it should be noted that some frameworks simply refuse to support services with in/out parameters). So in this case, you use the IntHolder class, which you can use to pass in the value and have it be modified and returned to you. In the code in the example, the values aren't actually accessible after the method invocation, but by changing the code to the following you can then inspect the values of the parameters you're interested in afterwards:

    IntHolder arg1 = new IntHolder(0);
    UpdateCountsTypeHolder arg2 = new UpdateCountsTypeHolder(new UpdateCountsType());
    WarningsTypeHolder arg3 = new WarningsTypeHolder(new WarningsType());
    Sp_customer_listResultSet1TypeHolder arg4 = new Sp_customer_listResultSet1TypeHolder(new
    Sp_customer_listResultSet1Type());
    MyASADatabaseServiceProxy.sp_customer_list(arg1, arg2, arg3, arg4);

Again, most services don't use in/out parameters, so this will only be needed occasionally.

Obviously, writing a Java service isn't a code-less exercise, or should it be. There are many steps taken so that you don't have to write the wiring code or have to deal with the intimate details of the interface language yourself, freeing you up to write the business logic of the service itself.

A (Mildly) Complex Example: Creating a Business Process Service in WorkSpace
The Business Process service uses a much higher-level language (BPMN at design-time and BPEL at runtime) to implement the business logic and, in fact, lets the user assemble the business logic using a graphical editor in combination with a tool palette without any coding whatsoever. Here we see how a simple Business Process service can be written that invokes the Java Service we wrote earlier but incorporates an additional validation rule: (See Figure 11)

As is the case with most WorkSpace Services, no coding was required to implement this logic. We simply dragged things from the Tool Palette onto the canvas, hooked up the wiring, and filled in a few simple details. Business Process services are somewhat analogous to the DataWindow in providing an enormous amount of built-in functionality that can be accessed without a great deal of low-level coding.

The Big Picture
As you can see, these varied kinds of services let you expose a vast array of existing technology as services and present and interact with those technologies in a uniform, ubiquitous way, all without writing a single line of code. In addition, you're by no means prevented from adding new code or new technology and integrating it in seamlessly. This enables you to make your technology choices as you see fit, be it by ease of development, by performance, by in-house experience, by existing code bases, or any one of a dozen criteria, without locking you into any of those choices. Some examples:

• If you had a large application that you wanted to rewrite in a different language, but couldn't afford to rewrite it all at once, you could expose its various components as services, create the application as a service-oriented application, and then begin selectively rewriting services one at a time as you had the time and resources.
• You could write an application based on a system of tradeoffs between ease of development and performance. Some services would naturally lend themselves to being Database and Message services, others require the flexibility and granularity of a Java service, others with complex interaction of services are best expressed as Business services, still others utilize the Transformation service's capabilities.
• You might have a mix of developers in-house, some of whom are strictly PowerBuilder developers, others strictly Java developers, and some better at high-level architecture than at writing code. You could let them work on the same application, each using their strengths, rather than forcing them all to use the same system and the same language and wasting valuable skills.

Summary
Service development, above all else, provides developers with an enormous degree of flexibility and makes designing and implementing robust, extensible, and maintainable applications easier to do than previous development paradigms have allowed for. WorkSpace, instead of simply providing a framework where services can be developed and used, provides a development environment where developing, deploying, testing, and using services is efficient and painless. You aren't forced to manually run tools to generate the interface for a given implementation or write obscure XML descriptors or code to wire services together, you can focus on writing your business logic and being productive right away. The same philosophy can be seen in the other aspects of WorkSpace, not just in service development and orchestration, so I encourage you to look into its enterprise modeling, database development, Web application development, and mobile development capabilities as well. Because, after all, isn't improving productivity without sacrifice what we're all really after?