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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-blueprints message

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


Subject: RE: Requirements document comments.


Hi Reza, 
 
There is a "glossary" at the end of the blueprints doc, but it's "to be implemented"
 
I think we can build such in the "official" wiki as soon as we get that posted...
 

>>>- Section 4.5.4.10 briefly discusses the notions of state-full and 
conversational services. The implementation of state-full services 
through a business process engine is an area that is of particular 
interest to me and I was hoping to find a more detailed discussion of 
this concept in the blueprint. 

I agree this is an interesting topic--presently most people implementing this are not using process engines--but this of course would be a very logical extension of best practices... We should certainly at least make note that stateful services for workflow can be implemented in such fashion and perhaps provide an example of such.

>>>>>Where should the logic for the orchestration of 
workflows between different systems, departments, or even organizations 
lie? I have some ideas on that but would be extremely interested to hear 
the expert opinion of the TC. 

Good question, I would be very curious to hear what others think on this question...

Let me ponder your "specific questions" and get back to you on those..

 

Best,

Miko

	-----Original Message----- 
	From: Reza Shafii [mailto:rshafii@bea.com] 
	Sent: Tue 10/11/2005 5:46 AM 
	To: Miko Matsumura 
	Cc: 
	Subject: FW: Requirements document comments.
	
	

	Hi Miko, 

	I just realized that point one below is partly covered by the "SOA 
	Blueprints Concepts" document. I had seen this document before but had 
	forgotten about it. My comment would really therefore refer to an 
	enhancement of this document. 

	Cheers, 

	Reza 

	-----Original Message----- 
	From: Reza Shafii 
	Sent: Monday, October 10, 2005 6:24 PM 
	To: 'Miko Matsumura' 
	Subject: RE: Requirements document comments. 

	Miko, 

	In general I found the document to be very well written and structured. 
	The language and format used is clear and easy to understand. Please see 
	below for my comments. 

	Cheers, 

	Reza 

	--------------: 

	General Comments and Questions 

	- I noticed that some of the definitions used are not consistent with 
	other sources I have come across. For example, each operation/interface 
	is referred to as a service (e.g. getEmployee and getDepartment). I have 
	sometimes seen a service defined as a group of related 
	operations/interfaces instead. There are also references to patterns 
	(e.g. Asynchronous Services) but the description of these patterns is 
	not substantial. 

	In order to maintain consistency and avoid duplication of a large 
	glossary on each blueprint, we might want to consider the creation of a 
	document that would contain a lexicon, set of definitions, pattern 
	descriptions, and concepts. This document could be referred to from all 
	blueprints. 

	Much of the content of this document could be references to existing 
	sources. Coincidently, reaching a consensus on the content of such a 
	document could also be a good way for us to start from a common ground 
	and understanding. 

	- Section 4.5.4.10 briefly discusses the notions of state-full and 
	conversational services. The implementation of state-full services 
	through a business process engine is an area that is of particular 
	interest to me and I was hoping to find a more detailed discussion of 
	this concept in the blueprint. 

	As an example, the blueprint as it stands seems to suggest that the 
	implementation should be done through separate business workflow 
	services. However, a single state-full workflow could also do the trick. 
	Also, given that the set of workflows compromising the end to end 
	process span different systems, having the entire process represented in 
	a single workflow can be tricky but desirable in many cases. This raises 
	an interesting question: Where should the logic for the orchestration of 
	workflows between different systems, departments, or even organizations 
	lie? I have some ideas on that but would be extremely interested to hear 
	the expert opinion of the TC. 


	Specific Comments and Questions 

	Page 10 - The service router is described as a (separate?) process. 
	Given that the work done by this router is purely technology specific 
	and has nothing to do with the business, could it be instead configured 
	into a service bus? Of course the work could also be done by the 
	security system's underlying platform? Should the blueprint make a 
	recommendation? 

	Page 12 - Do the WSDLs provided with the document include the XSD for 
	the message formats of the services defined? 

	Page 15 - How about an incorrect system ID exception response for the 
	unsubscribe call? 

	Page 19 - Line 22 - It appears that the table is referring to the wrong 
	operation. Isn't the operation at hand synchronous? 

	Page 22 - Figure 12 - More context info regarding the fact that this 
	diagram describes the security system's handling of a change message 
	from the HR system would be nice. 

	Figure 12 - Shouldn't the security system e-mail the administrator of 
	the legacy system in cases where there is no adaptor? 

	Figure 13 - Process doesn't check for an end system adaptor before 
	making the updateEmployeeRoles call. 

	Page 24 - Line 11 - Wrong operation seems to be referred to in table. 
	Isn't the operation at hand updateEmployeeRolesConfirmation? 

	Page 54 - Lines 5-9 - This statement is potentially an important element 
	(perhaps a "Best Practice") for any "Application Front End" or Service's 
	data access implementation in any SOA. Should this be highlighted as 
	such? 





	-----Original Message----- 
	From: Miko Matsumura [mailto:mmatsumura@infravio.com] 
	Sent: Monday, October 10, 2005 6:08 PM 
	To: Reza Shafii 
	Subject: RE: Requirements document comments. 

	Terrific. I am actually working on putting the requirements spec into a 
	wiki, and you may be able to put your comments directly therein. 

	Since this would be the first direct feedback of this kind in the TC, I 
	would like to have a look at your comments prior to kicking it out to 
	everyone... 

	Best, 
	Miko 


	-----Original Message----- 
	From:   Reza Shafii [mailto:rshafii@bea.com] 
	Sent:   Mon 10/10/2005 2:14 PM 
	To:     Miko Matsumura 
	Cc:     
	Subject:        Requirements document comments. 

	Hi Miko, 

	I have studied the requirement specification document and have a number 
	of general and specific comments and questions. 

	I am not sure what the TC process is. Should I go ahead and send my 
	comments as an e-mail to the TC mailing list? 

	Thanks, 

	Reza 

	________________________________________________________________________ 
	________ 
	BEAWorld 2005: coming to a city near you.  Everything you need for SOA 
	and enterprise infrastructure success. 

	
	Register now at http://www.bea.com/4beaworld 

	
	London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| 
	Beijing 7-8 Dec 




	________________________________________________________________________________ 
	BEAWorld 2005: coming to a city near you.  Everything you need for SOA and enterprise infrastructure success. 

	
	Register now at http://www.bea.com/4beaworld 

	
	London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec 



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