Web services and OO Inheritence

[Jim Akmer]

Hi,

I would like some input on the following somewhat generic question.
What is the support of inheritance of web services? Are web services meant to expose interfaces of this kind? It seems that the various frameworks support it using various "tricks" but is the message send to the client in a WS-I compliant format? The reason I am asking this is, because I have a problem with a web service that sends in the SOAP responce in the msg body the type using the xsi:type of the subobject send. The messages are very similar to the rpc/encoding format. Is this a valid approach to inheritance? Also is this the only option?
Thank you

[Jim Akmer]

The format of the messages is for example (trivial for demostration)

<s:Body> 
      <ns2:Resp xmlns:ns2="http://...anameSpace"> 

         <Person xsi:type="derivedType">.....</Person> 

      </ns2:Resp> 

   </s:Body>  

Is this type of messages to implement inheritance WS-I compliant? I could not find something concrete about the web services are meant to support OO completely. E.g. overloading is not supported.
Can anyone one help me on this?

[Jimmy Clark]

A web service is a run-time communication channel for two applications to communicate with each other. It is an "integration" technology, not an "implementation" technology.

Application A -------- > web service X -------------> Application Z

Application B -------- > web service X -------------> Application Z

Application C -------- > web service X -------------> Application Z

Web service X allows multiple applications to communicate with Application Z through the web. It provides a "connection" and "data transfer" service.

That said, there are different types of "web services." Some allow applications to connect and get data (data-oriented web-service.) Others allow applications to connect and execute a process (process-oriented web service.)

Web services technology is complex and typically requires one or more seasoned experts to get it right in an enterprise environment.

The concept of "service" in a SOA and a "web service" are different and not the same concept.

[Jim Akmer]

@Jimmy

A web service is a run-time communication channel for two applications to communicate with each other. It is an "integration" technology, not an "implementation" technology.

This communication channel though, is described via a wsdl which exposes the interfaces and the types among other things. For this communication channel, and how it can be accessed and what kind of data can be send through this channel, OO concepts are not applicable? Is this what you are saying? I am not sure how to interpret your answer in the context of my question. Could you please help me understand what you mean?

Thank you.

[Jimmy Clark]

This communication channel though, is described via a wsdl which exposes the interfaces and the types among other things.

A WSDL instance is used to publish the details of a SOAP-based web service.

For this communication channel, and how it can be accessed and what kind of data can be send through this channel, OO concepts are not applicable?

No, object-oriented design concepts are not applicable. A simple XML-based instance is what is being sent back and forth for SOAP-based web services.


Application A (C++ APP) -------- > web service X -------------> Application Z (COBOL APPLICATION ON MAINFRAME)

Application B (PERL APP) -------- > web service X -------------> Application Z (COBOL APPLICATION ON MAINFRAME)

Application C (JAVA APP) -------- > web service X -------------> Application Z (COBOL APPLICATION ON MAINFRAME)

Application D (.NET APP) -------- > web service X -------------> Application Z (COBOL APPLICATION ON MAINFRAME)


Multiple applications, written in many languages can all use Web service X to communicate with Application Z.

There would be no hard-coded or syntax-level dependencies between the client applications (A,B,C,D) and the server application (Z).

NOTE: Applications A,B,C,D have no knowledge of the design or technology of Application Z. Application Z does not care about the design or technologies of client applications.

[Jim Akmer]

@Jimmy: What you say is very interesting to me. So, you do not think that web services can be "self-contained"? I.e. a client sends a message to a web service, the core processing logic is encapsulated within the web service, and the result is send back. Because I thought this, is what W3C means in W3C Web Services when it says that a web service can be an application component. Additionally, do you have an explicit authoritative reference stating that the messages exchanged should be simple xml messages (as a result of the communication channels model you described) because I have to work with a wsdl (not created by me and deployed) that has defined complex types and derived types and the web service sends the derived type that the response should be converted to, encapsulated in the SOAP response message and this is happening because web services frameworks apparently allow it. If you can give me a reference on this would be if great help to me.
Additionally, what you describe thus far is very en-lighting to me.

Thank you

[Jimmy Clark]

Here is another example:

Application E (JAVA APP #1) -------- > web service Y -------------> Application M (JAVA APPLICATION ON AIX OS) -----> ORACLE RDBMS

Application F (.NET APP) ------------- > web service Y -------------> Application M (JAVA APPLICATION ON AIX OS) -----> ORACLE RDBMS

Application G (JAVA APP #2) -------- > web service Y -------------> Application M (JAVA APPLICATION ON AIX OS) -----> ORACLE RDBMS

web service O ------------------------- > web service Y -------------> Application M (JAVA APPLICATION ON AIX OS) -----> ORACLE RDBMS



Here Applications E,F,G, and web service O use web service Y to get a certain piece of sensitive data from an Oracle database. There is a highly secure firewall system in place and only Application M is allowed to connect directly to the database. Everyone else needs to get the data using web service Y and they are not exposed to any details of the actual database or Application M.


Keep in mind that in terms of Application E,F and G the data-oriented web service "is" an application component, or an integral part of the how the applications function. This does not mean that the web service is an application however. In other words, the application is the client that is calling the web service and the web service is an "application component."

In terms of the web service, it is simply a mechanism to access another application (the implementation.) Again, web services is an "integration" technology, not an implementation technology. When you attempt to mix and combine these guys, you are heading down the wrong path...

[Jimmy Clark]

So, you do not think that web services can be "self-contained"? I.e. a client sends a message to a web service, the core processing logic is encapsulated within the web service, and the result is send back.

I think a web service can certainly be designed the way you mention. However, I also think it would be a poorly designed web
service in direct conflict with the intent of the technology. This is similar to bundling all types of business logic, data processing
logic, presentation logic into one long JSP page. At a syntax-level it can certainly be done, and can be made to execute without error,
but is this a good design? Will it easily support change in the future? Is it easy to understand and to teach to others?

An application that has a web service interface or is "exposed" as a web service is sometimes described as a "web service" or
a "service-enabled application." And sometimes web writers and authors may not clearly describe what they are writing about. And in some cases the author
is describing the type of implementation similar to what you describe.

There are many different ways to design web services, but what I describe above is the easiest to understand and implement.

The XSD language is a complicated language and when it is married to other technologies, it typically makes them a burden, and difficult
to manage and implement, e.g. JAXB, web services. And in many cases XSD really is not required, but is simply there as a result
of someone's technical wet dream on caffeine. My perspective is tainted a bit by many years of SGML programming with DTD and
other esoteric languages that very few know about.

When you add XSD aspects to OO inheritence and "OO design aspects " of an implementation, and bundle this into the web service mix, you
will end up with a pot of technical mush... it may work, but is still mush.

Ideally, a web service should simply transport data, e.g. data values, method names to invoke, etc. Designers should avoid contaminating
a web service interface with "specialized" types which require overly complex coding and introduce dependencies. In practice, this typically makes
things more difficult than it has to be...a common sympton when there is an absence of business leadership and the
right amount of technical management.

Apparently, in your situation the web service author has forced you into considering all types of crap when attempting to write client code for
his/her web service. This is reflective of "this" implementation, but does not reflect modern best practice.

The following two books are very good and should help you understand the concepts of "service" in a SOA and "web service."

Service-Oriented Architecture (SOA) Compass: Business Value, Planning and Enterprise Roadmap
Published by IBM Press

Enterprise SOA: Service-Oriented Architecture Best Practices
Published by Pearson Education, Inc.

[shivendra tripathi]

The concept of "service" in a SOA and a "web service" are different and not the same concept.

@ Jimmy Clark: I would be great if you can provide some detail on this.

[Jim Akmer]

@Jimmy: Thank you, for your very interesting input. I will read the books. I have one question though. Since as you say:

a web service can certainly be designed the way you mention .... in some cases the author
is describing the type of implementation similar to what you describe ... what I describe above is the easiest to understand and implement

My understanding from this, is that what you describe is a "view" or best-practices approach. It is not a mandate. But unfortunately we would have to work with poor designed web services. I was wondering, is there any explicit statement in W3C or wsld or soap or WS-I standards specs that describe this as a guideline or that explicitly specifies to avoid implementations as I described? I would expect the up-to-date standards to be formulated in a manner that display the intention on how web services should be used in an integrated environment (I am not referring to concrete implementation of course). Something like "inheritence is not WS-compliant" the same way as overloading is forbidden. Because, from what you describe, by putting OO concepts in a wsdl, would possibly break interoperability or would force the clients to specific implementations, since only clients that are written in OO languages (clients in plain C for example would not be possible) could be used.
Should I understand that there is no such reference, only good patterns from experience?

[Jimmy Clark]

Sounds good. It now looks like you are on a good learning path. The material that I suggested is only the tip of a giant iceberg floating around the ocean of technology.

Good luck!

[Jim Akmer]

@Jimmy: Thank you, but I would prefer some kind of reference at least as support since I am going to have to actually work with the "poorly concepted" wsdl. It would be better for me to have some kind of reference instead of being argumentative over a theoretical approach, but it seems to me that I can not get help with that

[Jimmy Clark]

lol...you can certainly refer to this thread on JavaRanch.com as your reference. If you read the material that I suggested, and if you understand what the authors are saying, then you should be able to apply effective concepts and techniques in your own work in the future.

[Jim Akmer]

I think that this article Web Services Value Type Inheritance and Interoperability although not recent, in the Recomendations paragraph, gives a formal description of what Jimmy is saying.

[Jimmy Clark]

It is best to not expose intimate details of the implementation behind the web service. Moreover, client applications should not have any particular dependency on such implementation details. Ideally, you want to be able to change the implementation, without having to force changes in the client applications. You want to be able to easily adapt to change.

[Jim Akmer]

I agree 100% with what you say. My only "counter-argument" is that the web service current status allows to do this "poor" implementations. I.e. Frameworks (J2EE .NET and others) allows to expose these kind of implementation details, WS-I (as mentioned in the article) does not address this issue, or explicitly forbid it (IMHO there should be some explicit statement in WS-I Profile). And since current WS infrastructure allows it, how is it possible to convince for otherwise someone, who created a wsdl along these lines (in my original post), when he might also have the additional "counter-argument" (besides of the fact that the bad approach as discussed is not forbidden by authoritative specs) of object re-usability? One could say for example that this way, he does not have to create extra classes to encapsulate the information send/received in the web service, but keep the same business classes, for the web interface as well (ignoring annotations etc) thereby having less classes to maintain, also does not have the overhead of mapping from the class received/send by the web service to the domain class, less error prone since any change in the business domain classes would not have to be updated to the web service classes since they are the same etc. and there by inherently adding the implementation details in the wsdl? I can not understand why web services docs are so ambiguous.

[Jimmy Clark]

Jim, technology specifications and standards should not attempt to dictate or enforce a specific type of design. Technologists should always be provided with as much freedom as possible.

By the way, you keep reffering to the 'wsdl'. It would be better to think in terms of the 'web service.' The WSDL (all capital letters because it is an acronym) instance simply describes the web service in question.

For something as complex as web service technology, there will always be arguments for different types of design styles. This is a fact of life and part of the challenge of software design. If you ever get to be the head honcho in charge of a design, then you will be able to implement your design style without obstacle. Until then well... simply pointing out web articles containing individual opinions will only get you so far.

Technology standards and specifications documents will never mandate a particular design style.....and they should not.

[Jimmy Clark]

The concept of "service" in a SOA and a "web service" are different and not the same concept.

@ Jimmy Clark: I would be great if you can provide some detail on this.

@shivendra: web services technology is an alternative to messaging with message ques, topics, JMS, etc.

Prior to web services, in distributed systems components communicated by sending messages back an forth.

As an alternative and potentially a more robust mode of communication, web services were created as a possible integration mechanism.

Web services are simply messages sent via HTTP from one application to another.

Now "services" in the terms of SOA is an entirely different animal. Keep in mind that a SOA can include web services for applications to communicate with other, but they are not to be considered the "services" of the SOA.

If you read the material I mention above, you will understand what I just wrote more completly. It is best to not attempt to learn technology by simply browsing the web. If you do this, you will only get a superficial understanding and also will be exposed to incorrect information as well.

Here is a quote to wet your technology taste buds

"The notion of a service is not fundamentally a technology concept, but rather an abstract respresentation of value the business wants to extract from its technology. It is important to define services from a business point of view since business processes fundamentally define the business."

[Vignesh Bhupathi]

I could not find something concrete about the web services are meant to support OO completely. E.g. overloading is not supported.
Can anyone one help me on this?

A simple program for overloading ! (In WSDL ,the operationName which we specified @WebMethod will be there , so it won't serve the purpose of overloading ) !!

  package com.ws.test;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.xml.ws.RequestWrapper;
import javax.xml.ws.ResponseWrapper;

@WebService()
public class TestWebService {

    @WebMethod(operationName = "stringReturn")
    @RequestWrapper(className = "com.ws.test.String_Request", targetNamespace = "http://test.ws.com")
    @ResponseWrapper(className = "com.ws.test.String_Response", targetNamespace = "http://test.ws.com")
    public String serviceMethod(String strReq) {
        return "strResp";
    }
    /*OverLoading*/

    @WebMethod(operationName = "intReturn")
    @RequestWrapper(className = "com.ws.test.INT_Request", targetNamespace = "http://test.ws.com")
    @ResponseWrapper(className = "com.ws.test.String_Response_I", targetNamespace = "http://test.ws.com")
    public String serviceMethod(int intReq) {
        return "intResp";
    }
}
  

WSDL (Generated (Java2WSDL) ) :

 
<message name="stringReturn">
	<part xmlns:ns1="http://test.ws.com" name="parameters" element="ns1:stringReturn" /> 
</message>
<message name="stringReturnResponse">
	<part xmlns:ns2="http://test.ws.com" name="parameters" element="ns2:stringReturnResponse" /> 
</message>
<message name="intReturn">
	<part xmlns:ns3="http://test.ws.com" name="parameters" element="ns3:intReturn" /> 
</message>
<message name="intReturnResponse">
	<part xmlns:ns4="http://test.ws.com" name="parameters" element="ns4:intReturnResponse" /> 
</message>

<portType name="TestWebService">
	<operation name="stringReturn">
		<input message="tns:stringReturn" /> 
		<output message="tns:stringReturnResponse" /> 
	</operation>
	<operation name="intReturn">
	    <input message="tns:intReturn" /> 
         <output message="tns:intReturnResponse" /> 
	</operation>
</portType>