[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
services will do when they receive that context, it's up to them.<br> <br> We could send these two messages to the two services...<br> <br> To service1<br> --------<br> <envelope><br> <header><br> <context><br> ...<br> <sessionId>Session123</sessionId><br> <logging>true</logging><br> </context><br> </header><br> <body><br> <drop-database>databaseA</drop-database><br> </body><br> </envelope><br> <br> To service2<br> -----------<br> <envelope><br> <header><br> <context><br> ...<br> <sessionId>Session123</sessionId><br> <logging>true</logging><br> </context><br> </header><br> <body><br> <drop-database>databaseB</drop-database><br> </body><br> </envelope><br> <br> <br> As you can see, the context is the same. What each service does with<br= > regards to the session (modelled by the transmission of the context),<b= r> it's up to the service. So, one could imagine a message only to service= <br> 2 like this...<br> <br> <envelope><br> <header><br> <context><br> ...<br> <sessionId>Session123</sessionId><br> <logging>true</logging><br> </context><br> </header><br> <body><br> <end-session /><br> </body><br> </envelope><br> <br> Now, the <end-session> message is not related to WS-Context. Inst= ead, it<br> says to the application logic not to do anything application-specific<b= r> with regards to the current context from now on (I hope I am not<br> misunderstanding the use of context... I am sure the WS-Context people<= br> will correct me if I do). The context has not been destroyed. In fact,<= br> it may still be used with service1. However, as far as service2 is<br> concerned, there is no association between the session (the<br> application-specific concept) and the context (the conceptually externa= l<br> entity that models the stateful interaction).<br> <br> What this means is that we have, again, a lifetime-related operation. I= t<br> is clear, however, that WS-Resource Lifetime cannot be used because the= <br> semantics of the message (the application payload) are only understood<= br> by the service logic.<br> <br> <br> Furthermore, David agreed that this message<br> <br> <envelope><br> <header><br> <context><br> ...<br> <sessionId>123</sessionId><br> </context><br> <databaseId>DatabaseA</databaseId><br> </header><br> <body><br> <drop-database /><br> </body><br> </envelope><br> <br> would be the way to go with WS-RF. But wait a minute (no one picked on<= br> that)... If DatabaseA is modelled as a WS-Resource, why isn't the<br> <drop-database> a WS-Resource Lifetime message? After all, we are= <br> destroying the database, which is modelled as a resource. I think that'= s<br> another example whether WS-RF wouldn't be used.<br> <br> <br> <br> Finally, with the WS-I or WS-Context approaches, it's very easy to say<= br> this...<br> <br> <body><br> <drop-database><br> <databaseId>databaseA</databaseId><br> <databaseId>databaseB</databaseId><br> </drop-database><br> </body><br> <br> If both databases were modelled as WS-Resources what would the message<= br> be? Would I have to send two messages, as it would be the case with any= <br> other object-based technology?<br> <br> <br> I hope you treat these questions as a way to investigate and better<br>= understand the applicability of WS-RF and its conceptual model and not<= br> as more fuel to a religious argument.<br> <br> Regards,<br> .savas.<br> <br> <br> </tt><br> </body></html>= --1__=09BBE432DFCB180C8f9e8a93df938690918c09BBE432DFCB180C-- --0__=09BBE432DFCB180C8f9e8a93df938690918c09BBE432DFCB180C Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=09BBE432DFCB180C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=09BBE432DFCB180C8f9e8a93df938690918c09BBE432DFCB180C Content-type: image/gif; name="pic05010.gif" Content-Disposition: inline; filename="pic05010.gif" Content-ID: <20__=09BBE432DFCB180C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=09BBE432DFCB180C8f9e8a93df938690918c09BBE432DFCB180C Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <30__=09BBE432DFCB180C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=09BBE432DFCB180C8f9e8a93df938690918c09BBE432DFCB180C--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]