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: [soa-blueprints] > Client Patterns


	I would go beyond it being a devilish detail by saying that it
could present equal complexity  to the patterns being defined on the
back end.  Consider a long running process in the context of a portable
client that is sometimes connected to the back end.  How does the static
nature of service react to being not always being in contact with the
environment that it is part of?
	Going further - how does the client side orchestration of
services define what happens in the back end?  Are there patterns that
define how these should interact with one another.
	Perhaps another way to ask this - is the client another SOA
container that defines how services interplay?
	Breaking this apart I see three classes of blueprints.  
		1. User patterns
		2. User/System patterns
		3. System patterns	




-----Original Message-----
From: marchadr@wellsfargo.com [mailto:marchadr@wellsfargo.com] 
Sent: Wednesday, November 30, 2005 11:54 AM
To: Mark Cowan; soa-blueprints@lists.oasis-open.org
Subject: RE: [soa-blueprints] > Client Patterns

This is a good point.

The devil is in the details of the client is come respects.
The blueprints should cover the client variations as well since in some
camps a portal is a type of service the customer is invoking that
orchestrates and coordinates information from other services through a
service client contract with the service providers of the backend.

I'll try and incorporate this into an area of the wiki to talk more

- Dan

-----Original Message-----
From: Mark Cowan [mailto:mcowan@adobe.com]
Sent: Wednesday, November 30, 2005 8:38 AM
To: soa-blueprints@lists.oasis-open.org
Subject: [soa-blueprints] > Client Patterns


	I see much of the discussion focused on how the interplay of
processes at the back end can/should be or not be defined.  However
nothing about what happens on the glass.  Noting that the majority of
the patterns and anti-patterns are expressions of how services work
together but then are surfaced up to users through two mechanisms -
portals and clients.   I find myself questioning much about the patterns
used to describe how services should even interoperate on the back end.
Meaning - by focusing only on the back are we missing a big part of the


Mark Cowan
e - mcowan@adobe.com
p - 613.940.3974
w - www.adobe.com

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