Title: RE: [asap] Factory in ASAP
Keith,
That's all reasonable too. But from time to
time you hit across stuff that is
debatable. Then you have to make a decision
to either include it now, or
defer it until later, or duck it.
If your goal is to get a published spec' out ASAP -
then you want to
restrict what you are taking on board. But
often you hit usage cases
that need to be address to ensure the specification
is robust and
sufficient in its first release. If such
extras can be address cheaply
in terms of effort and syntax, and minimal
side-effects - its usually
an easy call to go for it.
It's a judgement call for the team then to
make. I'd say you are still
relatively early in the process here so its good to
address these things
now. Obviously if someone raises something 2
weeks before you
are going out to public vote on a spec' - then
that's an easy "V2.0" call!
DW
----- Original Message -----
From:
Keith
Swenson
To: 'David RR Webber' ; Michael
Shenfield ; Keith Swenson ; Mayilraj
Krishnan ; Jeffrey Ricker
Cc: ASAP
Sent: Friday, November 07, 2003 1:56
PM
Subject: RE: [asap] Factory in ASAP
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:]
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:]
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:]
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:]
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:]
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:]
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:]
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:]
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.
