[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [asap] Factory in ASAP
ASAP should seek the commonality to all long running webservices. The core to wireless-friendly service protocol and workflow-friendly service protocol should be identical. Note the word CORE. I am very pleased with the exchange so far because it brings the forefront what is CORE. A wireless-fiendly protocol might not need monitor and control. Workflow-friendly, manual-friendly and data-mining-friendly do need monitor and control. A data-mining-friendly might need some things above and beyond what workflow-friendly. (Would that we knew). I take HTTP as a guide in thinking about such things. The absolute fundamental method in HTTP is GET. Not every resource needs POST method. Swenson has made it clear that for his needs he MUST have monitor and control. Shenfield has made it clear that he MUST NOT be burdened with monitor and control. To use the HTTP analogy, Swenson MUST have the POST method, or the protocol is useless to him. Shenfield MUST NOT be required to implement POST and still be HTTP compliant. Does that make sense, or have I taken the analogy too far? On Fri, 2003-11-07 at 13:56, Keith Swenson wrote: > But what is the charter if it is not the definition of the group? The > purpose of the charter is to define what is and is not suitable for > discussion in this forum. If we don't adher to the charter, then we > risk losing focus, and risk failing to produce anything at all. The > people that signed up for the group did so on a basis of what the > charter said. > > It is understandable that someone may have joined the group without > understanding completely the charter. To me, the essense of what > distinguishes an asynchronous service from other is the ability to > monitor and control it. It is not simply a normal service that takes a > long time. It is a service that might take long enough that you might > change your mind and cancel it. Without the ability to monitor and > cancel, we are not solving the problem defined by the charter. I am > open to discussion on this, but to me it is pretty clear. > > Michael is not interested in this. He instead is interested in > services that are wireless friendly. This is an interesting and > important topic, but this is not the "Wireless Friendly Service > Protocol" technical comittee. I deeply regret discouraging his input, > because he has provided the best input so far in the group, and he > clearly is knowledgeable in his field. But in order to fair to > everyone who has signed up for this group, I feel I must try to keep > the discussion focussed on the subject defined by the charter. > > If someone wants to change the charter, then please take that > discussion into a subcommittee and off the main list. Then propose > the new charter to the group and put it to the vote. Until that time, > I want to focus on the problem defined by the current charter. > > -Keith > -----Original Message----- > From: David RR Webber [mailto:david@drrw.info] > Sent: Friday, November 07, 2003 9:29 AM > To: Michael Shenfield; Keith Swenson; Mayilraj Krishnan; > Jeffrey Ricker > Cc: ASAP > Subject: Re: [asap] Factory in ASAP > > > Keith, > > Actually that's not at all so! The Charter is NOT set in > stone. You can change it - there is a process for doing that > - see the OASIS manual for that detail. > > However - perhaps a better solution here is to have a > subcommittee. The subcommittee can go off and research > "stuff" and then come back and recommend something to the main > TC. > > So - for instance - you could have a SC to investigate if the > charter needs to be extended, if that would be appropriate to > do, and if it makes sense for the TC to do it as an extension > of their original focus. > > To setup a TC you need to have a vote at your next meeting - > and then agree on what the terms of reference are for the SC, > then notify Jamie at OASIS - he sets up the SC area in Kavi - > and then members can signup there and participate, etc. > > Hope this helps. > > DW. > > > ----- Original Message ----- > From: Michael Shenfield > To: Keith Swenson ; Mayilraj Krishnan ; Jeffrey Ricker > Cc: ASAP > Sent: Friday, November 07, 2003 11:49 AM > Subject: RE: [asap] Factory in ASAP > > Well...if what you say about the charter is correct > and it's "carved in stone" than all discussions about > the scope are obsolete as it's predefined. In this > case I just retreat to observer status. I am not very > interested in "monitored and controlled" asynchronous > services as they are not wireless friendly by nature. > -----Original Message----- > From: Keith Swenson [mailto:KSwenson@fsw.fujitsu.com] > Sent: November 7, 2003 11:37 AM > To: Michael Shenfield; Keith Swenson; Mayilraj > Krishnan; Jeffrey Ricker > Cc: ASAP > Subject: RE: [asap] Factory in ASAP > > > The charter of this technical committee > specifically states that the asynchronous > service is something that that can be > monitored and controlled. This charter was > put into place to guide our discussion, and to > keep us from getting off track. Since you > agree that a factory is needed to be able to > monitor and control an asynchronous service, > then any discussion about alternate approaches > should be taken to a different technical > committee. > > Please understand, it is not that I don't > respect your position, or that I think the > problem you are tyring to solve is > unimportant. It is only that this technical > committee is set out to solve is the problem > defined by the charter. This technical > committee CAN NOT change the charter. In > order to accomplish that goal, we need to > remain very much focussed on what the charter > says. > > If you disagree with the charter, then make a > new charter and technical committee. It is > not hard. > > That being said, this technical committee MUST > have a protocol that allows for the monitoring > and controlling of an asynchronous service. > There may be ways that involve somthing other > than a factory, and I am open to discussions > about this. > > It is possible that a particular > IMPLEMENTATION of the protocol "degrades" such > that it instead of being monitorable and > controllable, it returns an error message > instead. I am not saying that all > asynchronous services must be controllable or > monitorable. But, the protocol MUST provide > for this capability. > > The 80/20 rule works as long as you meet > fundamental criteria. For example, a car is > not a car if it has no wheels. The 20% that > remains must include some sort wheels. The > fundamental criteria in this case is that a > service can be monitored and controlled. > > -Keith > > -----Original Message----- > From: Michael Shenfield > [mailto:mshenfield@rim.net] > Sent: Friday, November 07, 2003 7:13 AM > To: 'Keith Swenson'; Mayilraj Krishnan; > Jeffrey Ricker > Cc: ASAP > Subject: RE: [asap] Factory in ASAP > > > Re: "...Let me repeat my request from before: > Describe what must be done to > link > two systems at run time together such that one > can start a long term > process, > update it later, check its status, and > terminate it if necessary. It is > from > the dynamics of this linking that the > advantages of this approach appear..." > > Sure, if you want to do all these things > (update, check status, terminate) > you'll need a factory. Following 80-20 rule I > would assume that only 20% of > async service implementations ever need these > features, therefore I am > quite convinced that it would be an overkill > to include it in the spec as a > requirement for ASAP compliance. > As we represent two poles in the view on the > scope of specification we need > to let the rest of the group to express their > opinion, hopefully we will get > a features list from Jeffrey anytime soon and > be able to vote on specific > features to be included/excluded. Essentially > it should solve an argument > about the need for a factory. > Cheers, > > Mike > > > > > -----Original Message----- > From: Keith Swenson > [mailto:KSwenson@fsw.fujitsu.com] > Sent: November 7, 2003 9:50 AM > To: Michael Shenfield; Keith Swenson; Mayilraj > Krishnan; Jeffrey Ricker > Cc: ASAP > Subject: RE: [asap] Factory in ASAP > > > > > >> Your other example is with 1,200,000,000 > operations. Again I am puzzled. > >> Why not to have just 4 operations Create, > CheckStatus, Change, and Cancel > > >> while passing an SSN as a parameter(part)? > Of course, in this case it would probably be > better to do what you suggest. > The example was bad, but all I was using it > for was to show that factories > can > be "virtual". A better example might be that > the factory address includes > the > name of a Java class which is a servlet to be > invokved. Or it even could > specify > the method on a particular class. The point > is that there does not need to > be any additional overhead just because there > are a number of "factories". > >> I think the mechanism of Web Service > instantiation > >> should be left to framework providers. > Of course it should. Please don't confuse the > creation of a web service > with the creation of an Asynchronous Service > Instance. Creating an instance > > of the service, is not really creating a new > web service. Just like > creating > and instance of an object is not creating any > new methods. > >> We have prototype Web Services ... and > nowhere had to worry about > "factories" > As I mentioned, there are an unlimited number > of ways to do things. The > need for > factories comes only from wanting to link to > systems that expect factories. > You probably never did this. > Let me repeat my request from before: > Describe what must be done to link > two systems at run time together such that one > can start a long term > process, > update it later, check its status, and > terminate it if necessary. It is > from > the dynamics of this linking that the > advantages of this approach appear. > (And think back to the beginning of the OO > days when all the programmers > were pointing out that any program can be > written without using OO > constructs. > The difference lies not in the program, but in > the ability to reuse it in > many different situations.) > -Keith Swenson > P.S. We have some unfinished issue from an > earlier conversion. I was > hoping that someone else would chime in, but > since they have not I will > follow with a separate message. > -----Original Message----- > From: Michael Shenfield > [mailto:mshenfield@rim.net] > Sent: Thursday, November 06, 2003 8:17 AM > To: 'Keith Swenson'; Mayilraj Krishnan; > Jeffrey Ricker > Cc: ASAP > Subject: RE: [asap] Factory in ASAP > > > Wow...that's a long email. I had a hard time > reading it on my Blackberry at > breakfast :) > Now to the point. I don't think anybody argues > the importance of "Resource > Oriented" approach, that's why people define > multiple Web Services (and > ports) instead of offering just one Web > Service with a large number of > operations. Your analogy with object-oriented > vs. procedure-oriented? > True...the concepts are related somehow. My > question is what it all has to > do with the Factories? Your example on car > repairs only shows that one has > to define two web services > "CarRepairAppointment" and "AccessoryOrder". > Your > > other example is with 1,200,000,000 > operations. Again I am puzzled. Why not > to have just 4 operations Create, CheckStatus, > Change, and Cancel while > passing an SSN as a parameter(part)? And again > what it has to do with the > "Resource oriented" concept? Am I missing > something here? > Let me explain my position on Factory. I don't > have any problems with > somebody implementing the Factory as a web > service, I just don't see the > need for defining one in a standard. We have > prototype Web Services > implemented in .NET, WebLogic, SunONE, and > WebSphere and nowhere had to > worry about "factories" as Web Service access > and instantiation is taken > care by the framework. > I think the mechanism of Web Service > instantiation > should be left to framework providers, it's > non of the business of Web > Service developer. The Web Service just have > to be there for you when > accessing the port. As for ASAP specific > information it can be easily passed > > in the header (my "yes" vote) or as a > predefined operation (my "no" vote). > I've been programming COM and EJB for years > and was quite happy to see that > Web Services got rid of programmer-aware > "factory" concept, so I don't need > to call coInitialize(Ex), > coCreateInstance(Ex), etc. to get my COM > interface > > or to call EJBHome.create to get my EJBRemote. > Why do we need to go back in > time and define factory for ASAP? Could you > find "factory" as a principal > concept in any mainstream Web Services > specification? I am not aware of > any... > Cheers, > Mike > > > -----Original Message----- > From: Keith Swenson > [mailto:KSwenson@fsw.fujitsu.com] > Sent: November 5, 2003 9:02 PM > To: Michael Shenfield; Mayilraj Krishnan; > Jeffrey Ricker > Cc: ASAP > Subject: RE: [asap] Factory in ASAP > > > The factory concept is the central concept to > this whole approach. Of > course, there are an infinite variety of ways > that one might approach a > particular problem. This particular approach > uses a small number of generic > > "operations" on a large number of > "resources". The meaning of the operation > > depends on the address of the resource. This > is the "Resource Oriented" > approach. The other approach is an "Operation > Oriented" approach. > One should not be concerned about the > multiplicity of the factories. The > existance of a factory does not mean that it > takes up resources on the host > machine. The factory address can have data > values encoded into it. I can, > if I wish, claim that I have 300 Million > factories, one for each person in > the USA, by making the factory address have a > SSN as a parameter (or any > other disambiguating value) in the address. I > don't have to make 300 > million records ahead of time. There is, > then, no reason to try to reduce > the number of factories, nor is there any > basis to equate a minimal number > of factories to a minimal feature set. > The WWW functions on this principle of a few > operations on a large number of > > addresses. For example, instead of using the > web, you could define an > operation to retrieve the basic page, then an > operation to retrieve each > graphic on the page, and another operation to > retrieve the style sheet for > the page, etc. Some people would claim that > this is a "good" way to design > the system because getting the style sheet you > use an operation specifically > > for getting the style sheet, and what you get > back from this operation is > always a style sheet. Hence, it is strongly > typed. Instead, the web merely > > makes the page, the graphics, and the style > sheet have different addresses. > The same GET operation can be used to get each > one. Plus, I can remain > confident that if the future brings a new data > type that can be embedded in > a page, the same GET operation can retrieve > that data equally well. Some > people will complain that to display a page > you need to make a number of GET > > operations instead of one. True. Those same > people might argue that a > single XYZ operation would be "simpler". This > is NOT true, because the > specific information about the XYZ function > must be specified some way in > order to get the basic linking accomplished. > One problem, among many, is > that servers and browsers need to be upgraded > simultaneously in order to get > > new capabilities. Simultaneous upgrade does > not happen in the real internet > > world. > Back to ASAP: lets consider a real example. A > car dealer has two > asynchronous web services: one that people can > use to make an appointment at > > the garage to get their car repaired, and the > other to order a particular > accessory for a car. The reason I pick these > examples is because they are > things that have a "duration" -- they persist > over time. There should be no > > disagreement that for a customer to arrange > for a repair appointment some > data (expressed as XML) needs to be sent from > the customer to the car > dealer, and that for ordering a accessory a > different set of data needs to > be sent. This discussion then is really just > over how to talk about how > these two pieces of data are different. Some > approaches will make the > "operation name" be different between the two > blocks of data. The ASAP > approach makes the "address" be different. > For this scenario, using an "Operation > Oriented" approach, we could define > operations for CreateCarRepairAppointment, and > CreateAccessoryOrder. We > would also need to define operations for > CheckCarRepairAppointmentStatus, > CancelCarRepairAppointment, > ChangeCarRepairAppointment, > CheckAccessoryOrderStatus, > CancelAccessoryOrder, and > ChangeAccessoryOrder. > The instance is automagically created behind > the scenes, the correlation is > encoded somewhere in the data passed. > Using the "Resource Oriented" approach, we say > there is an address for > "CarRepairAppointment" and a different address > for the "AccessoryOrder". > Specifically, these are the addresses of the > factory. Knowing these > addresses, we can call the generic > CreateInstance operation. We get an > instance address which has the correlation > information encoded into it. We > then can call the generic Cancel (actually > Terminate), Check (actually Get), > > and Change (actually Set) on the instance. > As you can see there is a one to one mapping > between these two approaches. > The same number of actual messages is passed, > the same amount of data must > be stored. > The reason for taking the "Resource Oriented" > approach becomes more clear > when you carefully consider what must be done > in order to link two systems > together. There are systems that are designed > to be able to start remote > asynchronous processes. They already know > about the basic operations: > Create, Get, Set, and Terminate. In order to > link such a system to the > remote service, you must give it the > information to link. Using the > resource oriented approach, you only need to > give it the address of the > Factory resource. On the other hand, using > the "Operation Oriented" > approach, you must first tell that system > which operation is the create > operation. You have to program this somehow. > You must tell it which > operation is to be used to cancel the remote > service. Etc. > Once you buy into the basic idea that actual > operation is a combination of > an address and a generic operation, there are > some very cool things that can > > be accomplished very easily: Imagine that > company G build (through any > means) a system that automatically call the > AccessoryOrder operations. > Company G is a trusted partner who brings a > lot of business, so the car > dealer implements a "Pre Approved Accessory > Order" that handles the order in > > an expedited manner. Simply by changing the > address of the factory, all the > > associated operations are changed congruently, > and the system interacts with > > the expedited process. > For this discussion, I used a > NamingConvention: CreateXXX, CheckXXXStatus, > ChangeXXX, and CancelXXX. This might be an > alternative way to get the same > benefit. No such naming convention exists. > The naming convention approach > gets really nasty when you want to encode > something like a SSN into the > address. You would have 1,200,000,000 > operations. We can easily > communicate addresses of a factory, but > communicating the names of the > correct 4 operations from a field of 1.2 > billion is somehow less > comfortable. Of course you could hide this by > having 300M virtual WSDL > files (generating on demand of course so it > does not take any space) but the > > linking of operations is normally considered a > design time activity. Most > systems to call remote processes are not > really designed to take a WSDL file > > at run time, search out the operation > necessary according to a naming > convention, and then call that operation. It > is messy if you want this kind > > of flexibility. On the other hand, the > "Resource Oriented" approach is > designed for exactly this kind of flexibility. > In summary, please think carefully about the > "DYNAMICS" of linking systems > at run time as is necessary in a real life > internet environment where change > > is constant, and the systems you are linking > to are not under your control. > -Keith > -----Original Message----- > From: Michael Shenfield > [mailto:mshenfield@rim.net] > Sent: Wednesday, November 05, 2003 1:47 PM > To: Mayilraj Krishnan; Jeffrey Ricker > Cc: ASAP > Subject: RE: [asap] Factory in ASAP > > > I already expressed my concerns about > "Factory" concept. In all existing Web > > Services platforms that I am aware of the > "Factory" is invisible for the WS > developer and non of her/his concern at the > time of development and > deployment. I think we should step back and > define a minimal scope of ASAP > (as agreed at the last two conference calls). > I doubt "factory" should make > it there. > -----Original Message----- > From: Mayilraj Krishnan > [mailto:mkrishna@cisco.com] > Sent: November 5, 2003 3: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.p > > hp. > > > 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.ph > > p. > > > 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.ph > > p. > 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.ph > p. > > 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]