Re: [wsrp-primer] Re: [wsrp-markup] Re: [wsrp-primer] A consistentuse-case for primer

[Subbu Allamaraju <subbu@bea.com>]

Rich/Rex,

Could we hold on a bit so that the drafts can continue? For the parts 
I'm writing, I'm constantly referring to the scenario (here is what the 
consumer/producer is trying to do, and here is the message and so on), 
and it would be convenient to wait till we've a better picture for the 
flow and not change anything for now.

Regards,

Subbu

Rich Thompson said the following on 10/27/2003 07:24 AM:

>
> I am sensitive to the issue you raise. I find that the criteria for a 
> good example scenario are:
>
> 1. Involved enough to demonstrate the desired functionality
> 2. Simple enough that understanding the example does not detract from 
> understanding the functionality demonstrated.
> 3. Showy enough that it holds people's attention while they hear about 
> the functionality.
>
> Finding a good tradeoff between these three is never trivial. Easy 
> traps to fall into include:
> 1. A complex example that people outside of its domain never get their 
> head around (and therefore miss what is being demonstrated).
> 2. A "nothing new" example that causes people to ignore what is being 
> said.
>
> I think you are concerned that the current scenario falls into trap #2 
> while I am encouraging us to be careful for trap #1 as well.
>
> Thinking briefly about this, why not use the scenario from the 
> Whitepaper? It is both simple enough for people to rapidly grasp and 
> everyday enough for people to understand the value of having some of 
> the scenario being local (i.e. intra-company if not on the portal 
> server) and some remote. It demonstrates the value of the 
> functionality without getting into the issues of "aren't there better 
> ways than what you demoed in your portlets?" that Rex is raising for 
> the financial scenario. It also would tie the Primer to what we would 
> consider the more introductory material on WSRP, and in fact the 
> Primer can refer back to the White paper as providing such material.
>
> Rich
>
>
> *Rex Brooks <rexb@starbourne.com>*
>
> 10/25/2003 08:55 AM
>
> 	
> To
> 	Rich Thompson/Watson/IBM@IBMUS, wsrp-markup@lists.oasis-open.org, 
> wsrp-primer@lists.oasis-open.org
> cc
> 	
> Subject
> 	[wsrp-markup] Re: [wsrp-primer] A consistent use-case for primer
>
>
>
> 	
>
>
>
>
>
> Thanks, Rich,
>
> This is okay, but I really don't have the time to develop a second 
> scenario simply because it is more advanced. Nor do I have the time 
> and energy to put into attempting to persuade the group that this is a 
> significant enough issue to justify the extra work, but I will take a 
> last stab at it just in case I did not make a clear enough case. 
> Further, the reason why I think I was not clear enough is that I had 
> only seen the TV spots the previous evening. That is why I did not 
> have a clear alternative in mind--because I had not had enough time to 
> absorb the implications the TV ad presented in order to express my 
> concerns more cogently. The article Russell and I wrote (about which I 
> informed you 10/17) stimulated the presentaton opportunity which has 
> occupied me much of this week, and my preoccupation has delayed this 
> absorption.
>
> The point is not so much that the stock brokerage example is old and 
> familiar so much as the fact that some aspects of the use case are 
> being superceded in the marketplace by products on which advertising 
> dollars are being spent on media buys in the national broadcast and 
> cable television markets.This investment is being spent specifically 
> on "streaming" online stock market information.
>
> My point is also that this kind of media spending in this economy 
> means that people working in those marketplaces (media and stock 
> markets) will be aware of it, as will IT firms which sell into those 
> markets.
>
> I am not saying that the developers/implementers will be aware of it, 
> nor that it will enter into their concerns, but that it enter into the 
> concerns of the IT decision makers on whether to set the implementers 
> to work using WSRP/JSR168.
>
> Whether the IT decision-makers and the IT implementers discuss their 
> respective viewpoints is difficult to establish, and not worth basing 
> our decision solely on such an unfounded assumption. It is even more 
> difficult to guess if they include these kinds of discussions. 
> However, we need to understand the ramifications if they do. Would we 
> consider implementing a standard that uses an primer example that is 
> apparently being superceded in the media marketplace by spending on 
> media buys for apparently newer and faster information delivery systems.
>
> I know that is a lot of imponderable iffiness, in this, and that is 
> why I am not going to start any work on the basis of guessing if my 
> points persuade anyone, but continue working on what we have, not on 
> my suggestions.
>
> However, as an advertising person, I would be making the case to us, 
> if we were my client, to use an example that does not run the risk of 
> being considered passé in the perceptions of_ IT decision-makers, not 
> implementers_, since, except in software engineering firms, it is not 
> usually the implementers who make these decisions.
>
> Regardless, as convoluted as this is, I did want to attempt to make it 
> somewhat more clear. It boils down to making our standard clearly 
> cutting edge in the perceptions of our marketplace--the IT 
> decision-makers, be they software engineers or software engineering 
> company executives.
>
> Now that I have made everything clear as mud, I also want to point out 
> that we should consider modifying our example. I believe this, due 
> simply to the fact that we are starting with a web application within 
> our web services model, and I think implementers will conclude that 
> our standard is only for web applications in web services. I feel more 
> confident in saying this because I have worked with software engineers 
> and software engineering executives, and a more literal-minded group 
> would be hard to find. So, while I am not going to do more than leave 
> the issue open, I do think we better consider starting out with a 
> portlet that just delivers lists of stocks and prices, and maybe some 
> analyst reports, and add the application as the more advanced element 
> later, since it requires actual remote manipulation of the data, if 
> the app doesn't live on the client machines. (Which I would assume 
> from the current scenario, that it does not.)
>
> Ciao,
> Rex
>
> At 12:41 PM -0400 10/24/03, Rich Thompson wrote:
> While I appreciate the concern that the primer not reuse such an old 
> example that people wonder what is new or useful here, it is also true 
> that a  familiar base example keeps understanding the example from 
> distracting from what it is supposedly demonstrating. Perhaps a useful 
> middle ground is to use a familiar (even overly familiar) example for 
> walking through the interfaces and then double back for a "More 
> advance, real world example" in a section of its own. This provides a 
> simple learning ground and then walks the reader through the process 
> of designing a realistically complicated scenario. Comments?
>
> Rich
> *Rex Brooks <rexb@starbourne.com>*
> 10/24/2003 12:44 PM
> To
> wsrp-primer@lists.oasis-open.org, wsrp-markup@lists.oasis-open.org
> cc
> Subject
> [wsrp-primer] A consistent use-case for primer
>
>
>
>
>
> Hi Folks,
>
> After our primer telecon yesterday, when I hastily withdrew my
> objection to using a stock brokerage/portfolio management example,
> for various reasons I don't want to belabor in this message, I got to
> thinking about it some more and decided I really don't think that it
> is a wise choice after all. I have been banging my head against all
> the older scenarios, and was reminded in most of them that there were
> problems here and there with most, as well as with my own current
> project, building a presentation of WSRP and CAP (Common Alerting
> Protocol) from the Emergency Management TC.
>
> One of my concerns was that it would be best to have one example
> follow through the tutorials we put into the primer, and that this
> example be used for demonstrating the publish, find, bind features in
> the Registration Interface, including use of both UDDI and ebXML, in
> keeping with our plan to offer real-world examples and code (examples
> and code that would work, that is, not the actual Portals or Services
> of the example). It must also fit with demonstrations of the Service
> Description Interface, Markup Interface and Portlet Management
> Interface, all of which it does.
>
> So, while going over the primer thus far and continuing to review the
> use cases and scenarios we have dealt with in the process of building
> WSRP 1.0 and moving now into issues for 1.1, I decided that I could
> offer an alternate example by adapting the "Search UDDI..." scenario
> Andre worked up and which is available in the documents section of
> the WSRP webpages.
>
> However, before I actually include it in my edit of the current
> primer and start asking for assistance in building some sample
> portlets and a Portal Design exercise as part of the Markup
> Interface, I wanted to share this idea with you all and ask if it
> makes sense to you and if you would be willing to use it.
>
> From our Scenario Form Description: HealthCareConcerns, LLC., is a
> Portal development company, specializing in horizontal Medical
> Information Resources (Medical Informatics), including a searchable
> database of insurance providers, and vertical Medical Supplies
> procurement/supply chains. It develops a broad range of
> Healthcare-related Portals using domain-specific expertise from
> related but unintegrated market segments in order to focus on making
> itself a Healthcare Information Clearinghouse.
>
> HealthCareConcerns, ILLC., designs and builds specialized sites for
> knowledge-base delivery clients, by integrating domain-specific
> Portlets into Portals that service a range of information providers
> from specific niche markets to more broadly based Heathcare market
> segments, such a Home-based Elderly Care Products and Services or
> Maternity-related products and services. It will use UDDI and ebXML
> to publish its services and the services of its Portal clients and to
> search for new Portlets, based on an initial profile it makes of its
> specific clients.
>
> While some of the expertise and knowledge I have developed over the
> last several years can be used in this, it is not strictly an
> instance of the proof of concept Public Healthcare Preparedness
> Portal I am working on. However, I won't say that it doesn't also fit
> into other plans I have, but I always try to make any project serve
> more than a single purpose if I can.
>
> This scenario also provides what I think is a decent range of the
> kinds of Portals and Portlets WSRP can facilitate without either
> relying on either well-used examples such as stock market/brokerages
> or purchasing orders. Of all the previous scenarios the one I would
> have chosen as both simple and fairly straight forward was the memory
> configurator, but it has a couple of problems, mostly due to its
> being a customization example, which is a bit ahead of 1.0.
>
> Please let me know what you think. I am asking the markup committee,
> too since this is probably where I will be asking for samples
> regardless of which scenario we choose to follow through with for the
> Tutorials.
>
> Ciao,
> Rex
> --
> Rex Brooks
> GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> W3Address: http://www.starbourne.com
> Email: rexb@starbourne.com
> Tel: 510-849-2309
> Fax: By Request
>
>
> -- 
>
> Rex Brooks
> GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> W3Address: http://www.starbourne.com
> Email: rexb@starbourne.com
> Tel: 510-849-2309
> Fax: By Request