Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 99480 invoked from network); 21 Apr 2005 08:48:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 Apr 2005 08:48:54 -0000 Received: (qmail 24710 invoked by uid 500); 21 Apr 2005 08:48:57 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 24679 invoked by uid 500); 21 Apr 2005 08:48:57 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 24662 invoked by uid 99); 21 Apr 2005 08:48:56 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from mail.opensource.lk (HELO squid.cmb.ac.lk) (202.51.147.3) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 21 Apr 2005 01:48:56 -0700 Received: from gandalf ([220.247.243.133]) by squid.cmb.ac.lk (8.12.9/8.12.9) with ESMTP id j3L8sjE5080404 for ; Thu, 21 Apr 2005 14:55:02 +0600 (LKT) (envelope-from chathura@opensource.lk) Message-Id: <200504210855.j3L8sjE5080404@squid.cmb.ac.lk> From: "Chathura Herath" To: Subject: RE: [Axis2] Deploying MessageReceivers per Operation Date: Thu, 21 Apr 2005 14:47:52 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C54681.225A35B0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <007f01c5462a$cca95f70$2165a8c0@Deepal> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVGK9iEoAKs8+sUTyy8F5Ob24Z2XgAHkD3g X-Virus-Scanned: by amavisd-new X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C54681.225A35B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jaliya, Deepal, all I think we haven't looked at the problem in the correct angle. MEP and Operation have a one to many relation ship so it will not be right to say we let each operation have its own message receiver, neither it is correct to say we should have a message receivers per service because the MEP is defined per operation. Many Operation --> use--> One MEP The problem that jaliya has pointed out is very valid and believe we need to give proper attention. But we have missed out one salient point here. The original MEP was an IN_ONLY MEP but since the operation requires secure conversation the security module need to send out a message and get a message back. The point in that in this case the security module has created a new MEP(OUT_IN if you consider this EPR to be a server or it's the client side of the IN_OUT MEP ) which is orthogonal to the original MEP IN_ONLY. Further more now the endpoint has two parallel MEP's running 1) Original IN_ONLY MEP :- This will have a receiver - a InOnlyReceiver 2) OUT_IN MEP created by the security module :- This will have its own receiver. (Like a normal client) Now I believe there are no misunderstanding of having MessageReceivers because above two message receivers will be provided and this operation and the security module can use them. And any other service who has IN_ONLY MEP can use the above message receiver. Am I right? Complications come when you want to use the same transport to get everything done. That we have to figure out a way to get the engine to reuse our old same transport. Comments? Cheers Chathura _____ From: Deepal Jayasinghe [mailto:deepal@opensource.lk] Sent: Thursday, April 21, 2005 10:30 AM To: axis-dev@ws.apache.org Subject: Re: [Axis2] Deploying MessageReceivers per Operation Hi Jaliya; I think we can handle operation basic receivers inside Message receiver , that is because when some one implement a service he has to write a MessageReciver for his service , so inside the messagereciver he can write all the logic he needs to handle operation basis reciever , that is inside messagereciver.recive() he can implement those logic. as an example MyReciver extends MessageReciver { public void recieve(MessageContext context){ MyOperationReciever myop = new MyOperationReciever(); myop.recieve(context); } } so if we do that in this way I think we do not need to define per operation basis receivers. Comments .... Deepal Hi All, According the current implementation of Axis2, when we deploy a service, we can specify one MessageReceiver (InOnlyMessageReceiver, InOutMessageReceiver etc..) per service. According to my understanding we should let the user to register one MessageReceiver per operation basis. Possible example would be as follows. We have a web service with IN-ONLY operation. However we need to let the service to implement the RequestSecurityToken operation according to the WS-SecCon. This operation is an IN-OUT operation. In this situation we have to register two message receivers to these two operations. In addition, the MEP is bind to an operation and the MessageReceiver is the one who is driving the MEP. So I think we have let each operation to have its own message receiver. thoughts ?? Thanks, Jaliya ------=_NextPart_000_0006_01C54681.225A35B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jaliya, Deepal, = all

 

I think we haven’t looked at = the problem in the correct angle. MEP and Operation have a one to many = relation ship so it will not be right to say we let each operation have its own = message receiver, neither it is correct to say we should have a message receivers per = service because the MEP is defined per operation.

 

Many Operation à = useà One = MEP

 

The problem that jaliya has pointed = out is very valid and believe we need to give proper attention. But we have = missed out one salient point here. The original MEP was an IN_ONLY MEP but since = the operation requires secure conversation the security module need to send = out a message  and get a message back.

The point in that in this case the security module has created a new MEP(OUT_IN if you consider this EPR to = be a server or it’s the client side of the IN_OUT MEP ) which is = orthogonal to the original MEP IN_ONLY. Further more now the endpoint has two parallel = MEP’s running

1)       = Original IN_ONLY MEP :- This will have a receiver – a = InOnlyReceiver

2)       = OUT_IN MEP created by the security module :- This will have = its own receiver. (Like a normal client)

 

Now I believe there are no misunderstanding of having MessageReceivers because above two message = receivers will be provided and this operation and the security module can use = them. And any other service who has IN_ONLY MEP can use the above message receiver. Am = I right?

 

Complications come when you want to = use the same transport to get everything done. That we have to figure out a = way to get the engine to reuse our old same transport. =

 

Comments?

 

Cheers

Chathura

 

 

From: = Deepal Jayasinghe [mailto:deepal@opensource.lk]
Sent: Thursday, April 21, = 2005 10:30 AM
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] = Deploying MessageReceivers per Operation

 

Hi Jaliya;

 

I think we can handle operation basic receivers = inside Message receiver , that is because when some one implement a service he = has to write a MessageReciver for his service  , so inside the = messagereciver he can write all the logic he needs to handle operation basis reciever , = that is inside messagereciver.recive() he can implement those = logic.

 

as an example

 

MyReciver extends MessageReciver = {

 

 public void recieve(MessageContext = context){

    MyOperationReciever myop =3D new MyOperationReciever();

    = myop.recieve(context);

  } 

}

 

 

so if we do that in this way I think we do not need = to define per operation basis receivers.

 

Comments = ....  

 

Deepal

 

Hi All,

 

According the current implementation of Axis2, when = we deploy a service, we can specify one MessageReceiver = (InOnlyMessageReceiver, InOutMessageReceiver etc..) per service. According to my understanding = we should let the user to register one MessageReceiver per operation basis. Possible example would be as follows.

 

We have a web service with IN-ONLY operation. = However we need to let the service to implement the RequestSecurityToken operation according to the WS-SecCon. This operation is an IN-OUT operation. In = this situation we have to register two message receivers to these two operations. In = addition, the MEP is bind to an operation and the MessageReceiver is the one who = is driving the MEP. So I think we have let each operation to have its own = message receiver.

 

thoughts ??

 

Thanks,

 

Jaliya

------=_NextPart_000_0006_01C54681.225A35B0--