Sanjiva, 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. 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:
#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. #4 - is a simple matter of throwing an exception on deployment, it's easy to change it later (depending on #5) #5 - ':' apprears in IPv6 (and seems non REST-ful). 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. Thanks, dims On 9/14/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > I'm *really* sorry for not being able to make it to the chat, but I > vehemently disagree with one of the apparent decisions of the chat. Its > about the question of visibility of services inside service groups to > other people. > > If we're going to add service groups into 1.0 then let's add them > properly. The reason we were pushing to get this in AFAIU was to make > 1.0 architecturally complete, and doing a half job does not cut it in my > book. So either we should drop it or do it right .. and now we've > started doing it already; so we have to come to an agreement on what's > "doing it right" :). [Remember that I was against putting it into 1.0 at > all but we decided to do it .. so let's do it right.] > > Let's see whether we can agree on the functionality first and then worry > about how to implement it: > > 1. There is a semantic to service groups; they are not just a convenient > packaging mechanism that is lost at runtime. So if you use the admin > tool and look at a running system, you will see the service groups etc.. > Without service groups existing as a real thing, the value they add is > very little. NOTE: the fact that they exist in the engine does not mean > users are aware of it. In particular, users *only* know about services > and know nothing about service groups. See #4 also below. > > 2. Service groups have the behavior that they share a single service > group context per running service group "instance." This IMO is what > makes service groups interesting - basically the fact that you can share > some state across the different services that belong to a group. Of > course, if you have such a beast then you need to have a way to find > yourself back into a service group instance for subsequent requests. > Doing that requires some correlation key to flow in the message (HTTP > session cookie, reference property, whatever) and for the dispatching > logic to take this into account and dispatch to the instance. > > 3. The fact that there is a shared context instance makes service groups > have a session nature to them. This IMO is a necessary feature - if > there's no way to share some state across a group of service instances > which belong to the same group then there's not much value of having > service groups. This is the same behavior at least I had envisioned (and > I thought Glen had advocated?) for the SessionContext stuff which we > never finished .. and which we have now coerced into > ServiceGroupContext. > > 4. As service groups are packaged as single .aar's, there is no way one > can say that a service S1 in foo.aar will collide with another service > named S1 in a separate bar.aar. If we require all services in all > service groups to be named distinctly, then we are telling users to not > only be aware of already deployed .aar names (which is what we do now > and which is fine) but also that they need to examine each .aar and for > those .aar's which are in fact groups, look at all the names users have > picked for <service>s which are inside the aar and avoid those too. > That's absolutely unacceptable! Thus, services within a service group > are logically "local" to the service group and the names must never > collide. > > 5. Following up on the same topic, since service groups are not exposed > to users (clients), the URL of the EPR must somehow carry sufficient > info to indicate which service the message is being targeted to. That's > why one needs some way to have the service group name and the service > name become part of the URL. We came up with the idea of using ":" as > the separator to combine the service group name and the service name to > create the external service name because that's not an XML name > character and it works perfectly for this scenario: the externally > visible name looks like a fixed string but we (the people who create the > EPR) know a bit more and will interpret it as a 2-part string. > > OK that's all for now .. more as we continue the discussion. > > Sanjiva. > > -- Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
