[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [asap] Generic Factory in ASAP
Perhaps the frustration lies in the choice of the word "factory". A rose by any other name would ... confuse the heck out of anyone. 1. Let us focus on the pattern of an asynchronous service for a moment without the word factory. 1.1 There is a resource on the Internet. 1.2 The resource has a uniform resource identifier (URI). 1.3 That resource generates XML. 1.4 That resource accepts XML and generates XML based on the XML it receives. 1.5 It takes more than 60 seconds for that resource to generate the XML. 1.6 That resource needs the ability to say to a requester, "The XML you asked for is not ready yet; where do you want me to send the XML when it is done?" 1.7 The requester can either (a) register an observer to receive the XML when it is done or (b) the requester can continuously send messages to the resource asking "Are you done yet?" 2. The primary issue is the question of simultaneous requests. 2.1 Requester A makes it request of that resource at time T 2.2 Requester B makes it request at time T+100 2.3 The resource completes the result for request B at T+200 2.4 The resource completes the result for request A at T+300 3. The approach specified right now is that each request is assigned to a different URI. 3.1 Requester A and B send their request to URI 3.2 Requester A is informed that the resource it wants is URI/T 3.3 Requester B is informed that the resource it wants is URI/T+100 4. Terminology 4.1 Every requester wants resource URI and knows the resource as URI 4.2 The resource they get is URI+ 4.3 URI is in the current approach called a "factory service" 4.4 URI+ is called an "instance service" 5 Appearance versus reality 5.1 There may not be any addition software objects whatsoever for the various URIs. 5.2 The asynchronous service might be implemented as one servlet for the URI that every request goes to any the URI for every result. That is, one object is the factory and every instance. 5.3 There could be one servlet that handles every asynchronous service and every instance of those services, as with Axis. 5.4 Alternatively, there could be a physical XML file written to the directory for every instance. That is, the instance resource is an actual physical resource. Perhaps not practical, but it is certainly possible. I am very eager to talk specifically about how this pattern applies to what Shenfield is thinking with wireless. On Fri, 2003-11-07 at 12:41, Mayilraj Krishnan wrote: > Not to disturb the other thread, coming back to the original question > of having "Generic Factory" for ASAP. > I thought will forward whatever I sent to Keith Swenson, > so that TC members can chime in. > > Regards > Mayilraj > > Date: Thu, 06 Nov 2003 09:40:44 -0800 > > To: Keith Swenson <KSwenson@fsw.fujitsu.com> > > From: Mayilraj Krishnan <mkrishna@cisco.com> > > Subject: RE: [asap] Factory in ASAP > > > > Keith > > Thank you for your nice email. > > I am in agreement with your concept on "Resource Oriented Approach" > > for > > asynchronous services. > > We can come up with some tool to generate factory for each async > > service but I think WS developers should not worry about developing > > factory for each service. > > The main problem in the factory pattern (similar to ASAP pattern) > > is, factory returns the address for service instance. > > Rather I would think consumer will use the address of the service > > instance (endpoint) and the factory > > will be used at the infrastructure level (feature in WSDL 1.2). > > Once the WSDL processor understands > > the feature (will be defined with ASAP url), it knows how to > > interact with the generic factory and coordinate with the service. > > I guess we should not be calling that entity as "Factory" but I > > could not think of alternate name. > > At this point I am not sure this way features can be implemented or > > the intention of the features to do this kind of services. > > > > Thanks > > Mayilraj > > At 06:30 AM 11/6/2003 -0800, you wrote: > > > Hopefully you have seen my other comment about factories. With > > > reflection on that, I would like to see how you would expect to > > > use a single factory for a "CheckInventory" operation and a > > > "Shipping" operation. > > > -Keith Swenson > > > > > > -----Original Message----- > > > From: Mayilraj Krishnan [mailto:mkrishna@cisco.com] > > > Sent: Wednesday, November 05, 2003 5:23 PM > > > To: Keith Swenson > > > Cc: ASAP > > > Subject: RE: [asap] Factory in ASAP > > > > > > > > > I was referring two web services.. One is check Inventory > > > and another is Shipping. > > > > > > > > > Thanks > > > Mayilraj > > > At 03:53 PM 11/5/2003 -0800, Keith Swenson wrote: > > > > > > > Could you clarify your example at this > > > > statement: > > > > > > > > > > > > >> I have two web services one is check > > > > inventory, shipping. > > > > What is the other? > > > > -Keith > > > > > > > > > > > > -----Original Message----- > > > > From: Mayilraj Krishnan > > > > [mailto:mkrishna@cisco.com] > > > > Sent: Wednesday, November 05, 2003 12:32 PM > > > > To: Jeffrey Ricker; ASAP > > > > Subject: [asap] Factory in ASAP > > > > So far I have been thinking we need just only > > > > one factory for ASAP > > > > implementation or > > > > the implementation of services could be > > > > conveniently placed under one > > > > logical ASAP factory. > > > > I have two web services one is check inventory, > > > > shipping. Why do I need to > > > > create > > > > two ASAP factory? I think the ASAP pattern is > > > > generic enough, it can just > > > > have one factory. > > > > [In terms of WSDL 1.2 we could map this to one > > > > ASAP (soap/transport > > > > protocol) binding and one feature)] > > > > Is that a right assumption? > > > > > > > > > > > > Thanks > > > > Mayilraj > > > > At 11:35 AM 11/4/2003 -0500, Jeffrey Ricker > > > > wrote: > > > > >I have attached files for describing the > > > > current draft of ASAP in WSDL. > > > > >These are rough draft documents that have not > > > > been proofed. > > > > > > > > > >The asap.xsd describes the payloads > > > > >The asap.wsdl is the basis for all ASAP > > > > services > > > > > > > > > >The concept here is to treat ASAP as a binding. > > > > The message structures > > > > >are all the same, the programmer only has to > > > > define the ContextData and > > > > >the ResultsData elements. > > > > > > > > > >The checkInventory.wsdl and productLevel.xsd > > > > files provide an example of > > > > >this ASAP-as-a-binding approach. > > > > > > > > > >Ricker > > > > > > > > > > > > > > > > > > > > > > > > >To unsubscribe from this mailing list (and be > > > > removed from the roster of > > > > >the OASIS TC), go to > > > > >http://www.oasis-open.org/apps/org/workgroup/asap/members/leave_workgroup.php. > > > > To unsubscribe from this mailing list (and be > > > > removed from the roster of the OASIS TC), go to > > > > http://www.oasis-open.org/apps/org/workgroup/asap/members/leave_workgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]