[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-pfb] [UDDI#1] How to represent Producer Service Reference
agree, not to big differences.
On the MUST vs. SHOULD question on portlets and their producer references:
SHOULD provides more possibilities or methods to choose from for a producer
to publish, on the other hand it enforces consumer to implement all methods
to make sure they are able to pick up all data.
MUST enforces a method, thus limiting the freedom, but at the same time
reducing complexity.
So basically it's a question of freedom vs. complexity.
On the idempotence of re-publishing:
I think just re-publishing doesn't work here. This is simply because keys
are generated at publishing time (you pass an empty key while saving), what
would happen would be double entries.
Example:
publish portlet 1 on X
publish portlet 2 on X
FAILURE, re-publish
publish portlet 1 on X
publish portlet 2 on X
publish portlet 3 on X
You get two portel 1 and 2 entries.
Basically this can always happen, but having a reference to the producer
might be helpfull to garbage collect.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | Andre Kramer |
| | <andre.kramer@eu.|
| | citrix.com> |
| | |
| | 01/19/2004 04:23 |
| | PM |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: wsrp-pfb@lists.oasis-open.org |
| cc: |
| Subject: RE: [wsrp-pfb] [UDDI#1] How to represent Producer Service Reference |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
This is turning into a rather deep thread, however, I don't think the
differences are that great. I seem to just be more open to allowing diverse
ways leverage UDDI. See <ak> below.
regards,
Andre
-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: 19 January 2004 14:49
To: Andre Kramer
Cc: wsrp-pfb@lists.oasis-open.org
Subject: RE: [wsrp-pfb] [UDDI#1] How to represent Producer Service
Reference
see my comments/answers inline in <rj>
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | Andre Kramer |
| | <andre.kramer@eu.|
| | citrix.com> |
| | |
| | 01/19/2004 11:07 |
| | AM |
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: wsrp-pfb@lists.oasis-open.org
|
| cc:
|
| Subject: RE: [wsrp-pfb] [UDDI#1] How to represent Producer
Service Reference
|
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
Firstly, I would include the possibility of other (unspecified) kinds of
producer reference in 3, and not restrict to only producer wsdl reference
(which we would not specify after all). If we can name this bigger option
"4", then I would go for that and drop 3 altogether.
As I already indicated, this (4) would strongly encourage a producer
service key to be used, and the additional complexity would only need to be
dealt with when a wsrp consumer goes to use a producer service.
<rj> I don't get the point here. The consumer would always need to go to
the producer service to retrieve the wsdl URL. This is what the data model
defines.
If we allow multiple and probably even not specified methods we end up
either with consumers picking up the data by merging the result sets from
the various methods (what to do if we do not have empty intersections?) or
by incompatible publish/find paradigms used by producer/consumers.
</rj>
<ak>
By ordering the methods and strongly encouraging the simple
WSRP_PRODUCER_SERVICE_REFERNCE I think the chances of ambiguity or failure
to understand a portlet binding can be made quite small.
</ak>
It's very much like how we allow a producer to support multiple Web
service bindings (SOAP http and https; DIME, SwA etc) via our wsdl.
<rj> well, basically we don't since they are not specified. The producer of
course may implement additional bindings and even portTypes but it then
must not expect any consumer to understand them.
So putting this back to the publishing model, we *must* define one crisp
method, to allow publish/find work in an interoperable manner accross
producer/consumer implementations. Of course a producer can implement any
further publishing scheme - but then in must not expect consumers to
understand it.
</rj>
<ak>
But MUST a publisher supply a WSRP_PRODUCER_SERVICE_REFERENCE based
binding? I think this is a SHOULD and not a MUST. Otherwise, other kinds of
references won't be allowed.
</ak>
However, our main difference seems to be on what types of query to support
(directly in UDDI, without client side result set filtering). I would say
we only need to support "find wsrp portlets and wsrp producers" which one
can do using the WSRP_PRODUCER and WSRP_PORTLET tModel keys.
<rj> this is definitly the basic one, I agree
</rj>
Producers are "businesses", as are *portlets*, at the logical level. The
fact that portlets are hosted in a producer service may not reflect
business level realities (e.g. a portlet hosted by an Application Service
Provider (ASP)).
<rj>
I would rather say they are business services.
But as of now this reflects the technical level of reality. This is how
WSRP is defined. A Portlet is hosted by a Prodcuer, and a Portlet handle is
valid within a Producer scope.
Therefor we naturally model this relation into the UDDI structures.
</rj>
<ak>
Nothing forces a producer to be a separate business or a business to be a
single producer.
</ak>
The "find all portlets in a producer service" is thus a second-level
implementation question only. However, we may want to support this, and the
(1) category based scheme can address this requirement when needed (as
Richard & Alan point out). However, I would not mandate it, preferring 2 to
1.
<rj>
I agree, it is not a firstl level business process question, because once
we now the producer we can discover all portlets from the service
description.
However I found that this must be usefull especially when making some
"garbage collection" in uddi.
We found that sometimes using network connections and having no distributed
transaction things might screw up.
Es an example when deleting a producer service from uddi one could easily
delete all the portlets from that producer, too.
It may happen that "dead" entries are made into uddi simply because we
don't have distributed transactions.
Imagine a portal publishing itself along with 20 portlets to UDDI.
Somewhere in the middle the network connection crashes (or whatever). You
may end up in an situation where your local transaction (storing
information about published portlets into the database) did not complete
(because you write to DB after UDDI returns success) and restart the
publishing. Know you may end up in published portlets you don't even know
about.
I think there are more use cases we might think of.
So to summerize I found this possibility to find the entities in either way
usefull and helpfull. However I agree that to pure "portlet business" this
may not be necessary.
</rj>
<ak>
I think UDDI publishing can be made idempotent quite easily. If a failure
occurs the publisher just tries to re-publish everything. Repeating this
until no failures occur will ensure that things end up consistent.
</ak>
This makes publishing portlets more flexible (and easy via UIs) but
requires consumers to discover binding information in the following more
complex way:
<rj> I don't see why we would really want this flexibility. It seems to me
that thing get more complicated.
On the UI: while exploring the web UIs out there we have seen various flaws
or features not implemented. Some web UI can do that other can to this.
I wouldn't restrict our model to just rely on current and evidently not
completly implemented web UIs. Rather than this I would rely on the UDDI
API spec, which is the only interface which defines the communication
between registries and clients.
I also wouldn't expect to extensive use of the web UIs and think most
products will do publish/find under the covers using the API.
Btw. allowing multiple methods of how things can be published even confuses
users even more.
As an example users would have to "mentally build the union" of the
different result sets - provided they recalled all methods how to obtain
the correct results.
</rj>
<ak>
The both bindingTemplate and category bag would only be used to publish the
same information in two ways if both are in use. That simplifies the
end-user interpretation of producer service reference information. After,
all it's the same producer, just referenced in different ways.
</ak>
a) look for producer_service_reference binding template (scheme 2)
b) look for producer_service_reference category information (scheme 1)
c) look for other types of producer reference (4, possibly 3 as first)
For the above, we would not specify (c), only allowing it by use of
MAY/SHOULDs and would re-order the document to favour (b/2) over (a/1),
which I did not do as I was only enumerating options.
regards,
Andre
-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: 16 January 2004 17:42
To: wsrp-pfb@lists.oasis-open.org
Subject: [wsrp-pfb] [UDDI#1] How to represent Producer Service Reference
We discussed different methods on how to represent a reference from the
Portlet to its hosting Producer.
Following has been put on the table yet.
1. use a categorization scheme
The Portlets businessService refers to a "Producer Service Reference"
tModel in its categoryBag, the keyValue holds the UUID of the Producer's
businessService in the registry.
See technote 5.3.1
2. use a binding template
The Portlet businessService contains an additional bindingTemplate with a
reference to the "Producer Service Reference" tModel, the access point
value holds the Producer's businessService UUID in the registry
See technote 5.3.3
3. Portlet businessService provides directly the Producer WSDL
Not discussed yet the details, but basicly would end up in an addition
bindingTemplate, with access point holding the WSDL location.
Additional discussion is centered around whether we want to allow for
multiple methods or concentrate on one.
First I would like to start by repeating my argument from the other
threads.
In general my opinion is that we should to establish only one way for the
representation of the reference.
I see the following reasons here:
Firstly by makeing things more complicated we raise the barrier for
implementors of the search funcionality.
Basicly when having Portlets published in different allowed ways we would
end up in the need for products which want to support their users with UDDI
search functionality to to a programmatical maintainance of result sets,
i.e.
the set of Portlets found by using method 1 needs to be merged with the set
found using method 2 (or 3,4...). It should remain the repositories domain
to deliver only one set so applications can pass it directly to the
enduser, i.e. we need to make sure that we disconnect data management and
programm logic.
Furthermore having multiple methods means also to have multiple queries
against the directory while in essence searching for one result set.
Secondly even if this can be done programmatically we also want to think of
users using the standard UDDI UIs (not using product's search facilities).
Here the users would have to manually merge the results sets which seem
cumbersome to me. Remember that we discuss the introduction of additional
methods because option 1. does not allow UI usage in some cases (some UIs
do not allow to enter the data needed to implement scheme 1). I was able to
use the SAP UDDI test registry UI to implement the scheme, while I was not
able to enter the data necessary in IBM's and Microsoft's UDDI UIs.
I would also question whether it makes sense to limit ourselves because of
UI limitations.
Thirdly making things more complicated might reduce acceptance of both
programmers and end users.
Let's look at two relevant use cases and the methods we have currently:
1. search for portlet(s), find producer hosting it/them, bind...
This is possible with approach 1. and 2. because a search for Portlets
would be basically a search for businessServices referring to the
WSRP_PORTLET tModel.
The question how best to obtain the reference to the Producer's
businessService can be left out here. It is clear that 1. and 2. both allow
it in a quite easy way.
2. search for Portlets that are hosted by a specific Producer
This is possible with scheme 1., here categorization can be utilized and
the Producer's businessService key can be set to limit the search result to
those Portlets which reference that particular Producer.
I was able to test this scenario with the SAP UDDI test registry UI, while
I was not for the IBM and MS registry for the given reasons.
With scheme 2. it is not possible to discover this relation since the
inquiry API does not allow to search for businessServices whose
bindingTemplate contains a particular value in its access point element.
In principle I could happily go either for scheme 1. or 2. depending on the
use cases we consider important. However use case 2. seems to me to be a
valid question and worth targeting a solution which answers that question.
For reasons of referencial integrity I would also discourage us to refer to
the Producer by holding the WSDL of the Producer in each Portlet's
datastructures.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
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/wsrp-pfb/members/leave_workgroup.php
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]