I had an excellent e-mail exchange with Jim and Savas about proper message orientation, and now I feel I have a much clearer concept. The way I have implemented DynaSOAr 2.0 is message-oriented, and loosely-coupled, but there is one drawback - the consumer will not be able to generate any metadata about the service and the messages it consumed with the current WS tools. In a proper message-oriented service, you need to define your messages first, and interact with the service by sending those messages, and not the business objects which is a common tendency in the current WS programming style. Locally these messages are "java objects", you create them and set their properties - but that is not the same as interacting with the service by sending your internal business objects.
What do I mean by these? Let's take a couple of examples:
(1) Sending business objects:
public class PurchaseOrder { }
public class OrderedItem { }
public OrderedItem processPO (PurchaseOrder myOrder) { }
This is the common style where you send your business objects (like PurchaseOrder) while interacting with your service. Effectively, you are exposing the internal details of your service, and also, you need to have several APIs (like deletePO, updatePO etc) to perform several different processing.
(2) Sending messages:
public class POMessage { }
public class ResponseMessage { }
public ResponseMessage processMessage (POMessage myMessage) { }
Here, you are explicitly sending messages, and not exposing your business objects. Ideally, you can have different types of messages, and the service should be able to deal with them differently based on the type of each message - by which it means you do not have to expose a CORBA-style OO interface.
So, this is the style I will be adopting for a revision of DynaSOAr 2.0 - "contract first", as it is termed in the WS-world these days.
And there is a "contract first" issue elsewhere too - my contract runs out on June 15th. Unless it is extended soon, I will not be able to finish what I started. Yes, I can always go back home (to India) and get another job there - but, in that case I won't be able to complete my PhD here - which will mean that I will have wasted a great deal of time...
I am a little tensed about this - hoping that something will come up soon.
What do I mean by these? Let's take a couple of examples:
(1) Sending business objects:
public class PurchaseOrder { }
public class OrderedItem { }
public OrderedItem processPO (PurchaseOrder myOrder) { }
This is the common style where you send your business objects (like PurchaseOrder) while interacting with your service. Effectively, you are exposing the internal details of your service, and also, you need to have several APIs (like deletePO, updatePO etc) to perform several different processing.
(2) Sending messages:
public class POMessage { }
public class ResponseMessage { }
public ResponseMessage processMessage (POMessage myMessage) { }
Here, you are explicitly sending messages, and not exposing your business objects. Ideally, you can have different types of messages, and the service should be able to deal with them differently based on the type of each message - by which it means you do not have to expose a CORBA-style OO interface.
So, this is the style I will be adopting for a revision of DynaSOAr 2.0 - "contract first", as it is termed in the WS-world these days.
And there is a "contract first" issue elsewhere too - my contract runs out on June 15th. Unless it is extended soon, I will not be able to finish what I started. Yes, I can always go back home (to India) and get another job there - but, in that case I won't be able to complete my PhD here - which will mean that I will have wasted a great deal of time...
I am a little tensed about this - hoping that something will come up soon.
