Title: 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.
