Business Delegate Pattern and Service Oriented Architectures

As I'm working in the lightly unfamiliar environment of J2EE these days, in the ongoing bachelor project.  I'm using lots of time getting all the pattern definitions right. Most recently the Business Delegate (Sun's blueprint) pattern was refreshed (all of this probably has been in my curriculum last year, but you can't remember everything either).

Influenced by Clemens Vasters talk on Service Oriented Architecture at Architect Forum in Oslo this december (have no URL to this talk, although there should be one somewhere), the Business Delegate Pattern seems to have some faults.

The whole point of this pattern is to abstract and simplify the presentation layers access to business services, provide looser coupling, and reduce network traffic. To accomplish this it's suggested that:

1. Client calls delegate to get the service handle (probably the string representation of the type name of the class providing the service)

2.The client uses this string handle to execute a service via the business delegate and gets something back.

Why should the client request a name this service first? If the business delegate exposes the possibility to give the client the proper name it should have been able to perform the concrete service in the first place.

Additionally I can't see the need for the client to know the real name of the business service on which to call in the second run.

In a SOA manner the client should only know of the service defitition and how fo format the message to send in order to get the intended reply according to the contract. This would provide the least possible coupling.

Maybe Sun should rethink this one? Or maybe I need to;)