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.
