Hi Dev;

I changed code to make sure that a service name is unique across the system , but I really really do not like to make the service name unique in this way by enforcing service author to do so.

In that case two service author can not write there services independently , meaning one service author has to know what are the services in the system. Therefore we break the idea of service isolation, because we can not download Axis2 service and use that. My idea is for 1.0 keep this but we definitely have to improve that.



Thanks,
Deepal
................................................................
~Future is Open~

----- Original Message ----- From: "Sanjiva Weerawarana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Thursday, September 15, 2005 11:01 AM
Subject: Re: [axis2] service groups (from chat)


Hi Dims,

Guiding principle was that our Service Group concept is an internal
detail that should not be visible in any of the artifacts (WSDL, EPR)
or on the wire.

+1.

Let's get enough implementation experience with this
before we go the whole hog. Am not convinced that we should let it
"leak" via EPR's (as in #5). Also please see below:

The issue of course is whether a string that looks like a string to the
outsides is a leak .. see my comments under #4.

#1 - No one said that we should not show SG's in UI's. It's ok to do so.
#2 and #3 - We still need to do them, yes, they should work the way
you outlined it.

OK cool.

#4 - is a simple matter of throwing an exception on deployment, it's
easy to change it later (depending on #5)

OK let's compromise .. let's do the pattern where we keep the names flat
(as in a string without colons) for now and we can throw an exception on
deployment (as you propose above). If (when ;-)) this becomes a problem
we'll decide how to put the SG name into the URL so we don't have to
tell users to rename stuff.

#5 - ':' apprears in IPv6 (and seems non REST-ful).

I agree its non RESTful .. but making it RESTful (which I'd prefer) will
amount to showing the SG concept in the URLs explicitly. Its kinda neat
though because then we could have
SG/SN[/op_name[/message_name[/msgid]]] .. totally RESTful way to refer
to everything.

Definitely post 1.0 :).

Let's get some code working w/o leaking our SG's, go thru the Alpha at
least and take a checkpoint later if life becomes unbearable.

+1.

Sanjiva.





Reply via email to