The traditional way to access Web service is to generate Web service
client first (mostly using Apache Web service project- Axis), the
produced Web service client including Java Beans for user-defined
types, interface for operations, stub class that implements operation
interface, and service interface and service locator that implements
service interface. The service locator is employed to get the stub
instance and with the help of stub instance, the operations of Web
service could be invoked directly.
However, as far as BTT is concerned, using the traditional way
to invoke Web service is infeasible. The detailed reasons are:
- In the client side, there are lots of user-defined JavaBeans,
interface, stub class, etc. which brings about great
pollution to the client. You need to know the WSDL URL at development-time and these stubs are
not portable because they depend on the implementation classes and should not be packaged as part
of an application.
- It is inconvenient to do data mapping between JavaBeans and BTT
CHA data. When invoking an operation of Web service with one Java™
Bean input parameter and Java™ Bean input parameter, you have to prepare the parameters one by one. When JavaBean is more complex than expected, such as the
array list inside it's, the generic
Bean serializer and deserilizer cannot work around, and we must write the corresponding
serializer and deserilizer respectively.
Compared with the traditional way
to invoke the Web service, WSDII (Web service Dynamic Invocation
Interface) invoker provides a generic way of invocation different
external Web services, introducing
a generic data object to represent any non-primitive data type, employing
IoC pattern to construct the business logic, and providing simple
interface to mapping data between BTT context and Web service.
- Generic Data Object: Whatever the non-primitive data
types are, whatever the complexity of the non-primitive data types are, Generic Data Object can represent them and handle the serialization
and deserilization problems automatically.
- IoC: Configuration all the Invoke parameters and logic in
the file invoker.xml.
- Data Mapping Mechanism: WSDII invoker can transform
data elements inside the Context to parameters of Web service operation and
then transform Web service return value after
invocation back to Context.
WSDII invoker makes use of Axis as Client runtime to invocation Web service. When the WSDII
invoker attempts to invoke one Web service, the following
information is mandatory:
- Endpoint: the end point of target Web service.
- Operation: the target Web service operation.
- Operation Parameter: parameter description, such as name, Java
type and mode.
- Non-primitive Data: request and response generic data object.