OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-assembly] [Issue 80] Proposed directional resolution


I think we should do the full job.
All the best, Ashok


Martin Chapman wrote:
> Simon,
> That's effectively what our proposal says!
> So the main point here is either we do nothing, or we do the full job; I don't think best practices help.
>
> Martin.
>
>
>   
>> -----Original Message-----
>> From: Simon Nash [mailto:oasis@cjnash.com]
>> Sent: 25 June 2009 14:37
>> To: ashok.malhotra@oracle.com
>> Cc: Martin Chapman; 'Jeff Mischkinsky'; 'Anish Karmarkar'; 'OASIS Assembly'
>> Subject: Re: [sca-assembly] [Issue 80] Proposed directional resolution
>>
>> Ashok,
>> It seems to me that the pub/sub model is very close to having services
>> and references wired to channels.  The OSOA spec does not express it
>> that way, but the conceptual similarity is clear.
>>
>> I think it would not be very difficult to build something similar
>> to the OSOA Events model using the OASIS PRD 1.1 Assembly Model plus
>> a channel component that provides the pub/sub functionality and is
>> wired to services and references whose interfaces follow a particular
>> pattern.
>>
>> I'll put my hard hat on now, before the rocks start flying!
>>
>>    Simon
>>
>> ashok malhotra wrote:
>>     
>>> As I have said before, wires and pub/sub are alternate means of
>>> communication and need to be presented
>>> side-by-side to provide the complete picture.
>>> All the best, Ashok
>>>
>>>
>>> Martin Chapman wrote:
>>>       
>>>> <oracle hat>
>>>>
>>>> What best practices are these?
>>>> Aside from using a jms binding that allows for loose coupling at the
>>>> connection level (you still need wires though) is there any
>>>> experience amongst us to suggest what "best practice" exists?
>>>>
>>>> IMHO the best practices from the oracle esb/soa space are embodied in
>>>> the eventing pub/sub additions.
>>>>
>>>> I also think we need to be much more precise about using the term sca
>>>> 1.1. This is an umbrella term pointing to a family of specs
>>>> (policy, assembly, ws-bindings, pojo, etc.) I see no reason why
>>>> eventing can't be part of the 1.1 family somehow.
>>>>
>>>> Martin.
>>>> </oracle hat>
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: Simon Nash [mailto:oasis@cjnash.com]
>>>>> Sent: 25 June 2009 12:08
>>>>> To: Jeff Mischkinsky
>>>>> Cc: Anish Karmarkar; OASIS Assembly
>>>>> Subject: Re: [sca-assembly] [Issue 80] Proposed directional resolution
>>>>>
>>>>> Jeff,
>>>>> I understand the value of events and pub/sub and I agree that SCA
>>>>> needs to move forward with adding these capabilities.
>>>>>
>>>>> My experience of dealing with customers is that they are OK if
>>>>> not everything arrives in a single release, as long as there is a
>>>>> clear roadmap for how improved capability will be added later.
>>>>>
>>>>> I thought the email from Jacques Durand on this subject
>>>>> (see
>>>>> http://lists.oasis-open.org/archives/sca-assembly-comment/200906/msg00016.html)
>>>>>
>>>>> was very interesting.  The approach he suggests in comment [12b] of
>>>>> documenting "best practice" for handing events with the current
>>>>> Assembly concepts might provide a way to achieve credibility for
>>>>> SCA 1.1 in the integration space while allowing the standarization
>>>>> of the full event and pub/sub model to proceed in parallel on a
>>>>> later schedule.
>>>>>
>>>>>    Simon
>>>>>
>>>>> Jeff Mischkinsky wrote:
>>>>>
>>>>>           
>>>>>> hi Simon,
>>>>>>
>>>>>> The problem we have with delaying putting in the event concept is that
>>>>>> we see it as a fundamental part of the functionality that SCA is
>>>>>> supposed to deliver. Essentially without eventing and pub/sub
>>>>>> support as
>>>>>> a first class citizen, SCA will not be seen as a credible solution in
>>>>>> the SOA-space in general; and the integration-space in particular --
>>>>>> its
>>>>>> two major targets. I know y'all laugh if i pull out the "our customers
>>>>>> tell us" chestnut, though in fact that IS true, especially for our
>>>>>> larger customers. In addition, it is critical to our internal customers
>>>>>> (the apps and integration teams), and analysts have made the same point
>>>>>> to us, repeatedly.
>>>>>>
>>>>>> Without a decoupled processing model that complements the existing SCA
>>>>>> service-reference model, we believe that SCA will not gain as much
>>>>>> traction and be a serious contender in the SOA-space, as it deserves.
>>>>>> Both our internal and external customers use both models to integrate
>>>>>> their applications and solutions. Pub-sub and event processing are
>>>>>> well-established and well-entrenched way of modeling, thinking and
>>>>>> programming in the integration-space and we strongly believe that SCA
>>>>>> needs to address them now.
>>>>>>
>>>>>> We just don't understand how in this day and age one can go out with a
>>>>>> message that SCA is the best implementation model for SOA without it
>>>>>> addressing one of the main design points of SOA - loose coupling, event
>>>>>> processing.
>>>>>>
>>>>>> When making the proposal to issue-80, we are very much aware of, and do
>>>>>> appreciate, the implications on the schedule. But we feel that it is in
>>>>>> the best interest of the SCA standard and its adoption to delay the
>>>>>> release of SCA 1.1, if necessary, to include support for pub-sub and
>>>>>> event processing. Without this inclusion, there is a real risk of SCA
>>>>>> not being taken seriously and proprietary eventing processing, pub-sub
>>>>>> extensions impeding portability and fragmenting the standard.
>>>>>>
>>>>>> We are also not clear on exactly how long a delay this will actually
>>>>>> create, since we don't know at this point when we will be in a position
>>>>>> to the meet the exit criteria, i.e. the test suites with 2
>>>>>> implementations.
>>>>>>   cheers,
>>>>>>   jeff
>>>>>> On Jun 22, 2009, at 12:53 PM, Simon Nash wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Anish,
>>>>>>> I am very concerned about the work involved in fully integrating
>>>>>>> the event concepts into SCA Assembly and presumably all the other
>>>>>>> SCA specs.
>>>>>>>
>>>>>>> At this stage in the SCA 1.1 lifecycle I believe our priority should
>>>>>>> be to close down the few remaining issues, complete the public
>>>>>>> reviews,
>>>>>>> and move to formal ratification of the SCA 1.1 standard based on the
>>>>>>> current specifications.
>>>>>>>
>>>>>>> Absorbing this major new piece of functionality into the SCA specs
>>>>>>> will have large implications and push out the completion of SCA 1.1
>>>>>>> by some considerable time.  IMO it would be better to look at whether
>>>>>>> the Events support could be standardized in some other form such as
>>>>>>> a separate delta or supplement to the SCA 1.1 base specs.  This would
>>>>>>> allow the current specifications to achieve standardization in a
>>>>>>> timely manner, followed by an SCA Events 1.1 standard when this is
>>>>>>> complete and ready to go forward.
>>>>>>>
>>>>>>>  Simon
>>>>>>>
>>>>>>> Anish Karmarkar wrote:
>>>>>>>
>>>>>>>               
>>>>>>>> I would like to propose that we use the contribution at [2], as a
>>>>>>>> basis
>>>>>>>> for a directional resolution for issue 80 [1]. Specifically, we
>>>>>>>> introduce the concepts of events, event types, producers, consumers,
>>>>>>>> channels; and the changes these concepts make to the existing
>>>>>>>> composite/component/componentType/constrainingType constructs.
>>>>>>>> If this directional resolution is accepted, I suggest that an inlined
>>>>>>>> document (with change marks) be produced that provides a merge
>>>>>>>> between
>>>>>>>> [2] and the existing latest version of SCA Assembly. This would then
>>>>>>>> serve as a basis for the resolution of issue 80.
>>>>>>>> Comments?
>>>>>>>> -Anish
>>>>>>>> --
>>>>>>>> [1] http://www.osoa.org/jira/browse/ASSEMBLY-80
>>>>>>>> [2]
>>>>>>>> http://www.oasis-open.org/apps/org/workgroup/sca-
>>>>>>>>
>>>>>>>>                 
>>>>> assembly/download.php/32379/SCA_Assembly_Extensions_for_Event_Processing_and_PubSub_V1_0.pdf
>>>>> ---------
>>>>> ------------------------------------------------------------
>>>>>
>>>>>           
>>>>>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>>>>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>>>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>>>>>
>>>>>>>               
>>>>>> --
>>>>>> Jeff Mischkinsky
>>>>>> jeff.mischkinsky@oracle.com
>>>>>> Director, Oracle Fusion Middleware                 +1(650)506-1975
>>>>>>     and Web Services Standards                       500 Oracle
>>>>>> Parkway,
>>>>>> M/S 2OP9
>>>>>> Oracle                                Redwood Shores, CA 94065
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>>>
>>>>>           
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>>
>>>>         
>>>       
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>     
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>   


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]