[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Fwd: Conversational services
| Hi Dave, I figured you would take me up on the offer :-) Responses inline. Jim On Dec 9, 2008, at 11:28 AM, David Booz wrote:
We may disagree that interop is more important than portability at this point but we should define what we mean by each term. Interop can mean many things: 1. The ability for different vendor runtimes to operate as part of the same domain. This isn't important to us as we have no desire to mix-and-match runtimes from different vendors. And if we did try, operations would have a fit :-) 2. The ability to specify binding information that will properly flow invocations using Web Services technologies from external non-SCA clients and to external non-SCA providers. This form of interop is important to us. 3. The ability to specify binding information that will support non-SCA Web Services extensions provided by other vendors. For example, support for stateful/conversational services provided by Microsoft .NET (Durable Services) and the JAX-WS RI. This is a nice-to-have but not essential. 4. Binding interop for SCA semantics. For example, the ability to flow an invocation using a binding between a client component hosted in one vendor's SCA runtime and a service provider hosted in another vendor's SCA runtime while preserving the range of SCA semantics. Again, this is a nice-to-have but isn't critical for us. Also, there are probably only a limited number of remote communications protocols which are standardized enough to make this possible. Based on the above and our experience, there is a clear pattern and priority that has emerged for us. This may be different for other architectures. For our requirements, protocol-level interop (#2) is important for a relatively small number of services (in comparison the the total number of services in our systems) that operate at the edge of the domain. These services tend to be very loosely coupled (e.g. passing self-contained documents) as they interact with clients and providers that are beyond our control (e.g. third-party banks). Most of the time they are not async due to the added complexities of getting non-blocking patterns to work reliably across vendors. Interop type #1 we would never use due to unnecessary complexity and operational issues it raises. Type 3 is a nice to have that we could potentially use and is more important than type 4 which we probably don't have much use for. So for us, order of importance is: 2,3,4,1. I would be interested in seeing how others building enterprise SCA applications would rank the above if they had to due so in absolute order. While type 2 interop (web services interop) which has some relevance to us, what is extremely important is skills portability. As for application portability, it is probably fair to say given the amount of extensibility provided for by the specs, SCA applications will be much less portable than their JEE counterparts. So while application portability would be a nice feature, we don't think it will be a reality for a very long time (JEE still isn't very portable for most enterprise scenarios) and will be less than what JEE has achieved. However, skills portability is very important to us and it is something that people should be able to expect from SCA in the short-term. We want to hire developers that have a basic understanding of core SCA concepts (e.g. services, composites, components, wires, bindings) and can use that understanding to quickly come up to speed with our applications.
That's a bit of an open ended question that I could probably talk about at length :-) It's interesting you started with web services. We actually don't view conversations over web services as a critical use case, although that may be a peculiarity of our application architectures. We only use web services for communication at the edge of the domain as we find them overly complex for what we need to do, and insufficient from a performance and reliability perspective. In other words, we only use web services for the most loosely coupled forms of interaction. The overwhelming majority of our remote intra-domain communications are via messaging ("the software formerly know as MQ Series", Oracle AQ) and to a much lesser extent, XML over HTTP. I suspect many other high-performance systems will adopt architectures similar to ours by relying heavily on messaging for remote communications inside the domain and web services for external communications. However, we have done work integrating our conversational infrastructure with web services technologies even though it is not used in production (as our other support is). The important thing is our conversational infrastructure is a separate concern from bindings and the subsystems that support the latter. This allows for the possibility of dynamically reconfiguring bindings and providing a more flexible implementation of binding.sca. The other feature it provides is the ability to support multiple modes of propagating correlation information. It's also interesting you started with WS-Addressing. Transport protocols are not my forte, but I've seen conversational support implemented in other systems using a variety of techniques. We have used two approaches with the idea that they are configured in applications hosted on our SCA runtime through policy. The first is by having the client "request" a GUID from our conversational infrastructure (this only involves an in-process, relatively in-expensive call) and propagate it via WS-A ReferenceParameters. This will then be included as a SOAP header on the callback. It's interesting to note the JAX-WS RI takes the same approach, as does one commercial BPEL vendor I have spoken with that has implemented engine managed correlation. For example, the following is an example of how the JAX-WS RI propagates conversational (or "stateful" as it is called) information: <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns1:getProductResponse xmlns:ns1="http://server.stateful/" xmlns:ws-a="http://www.w3.org/2005/08/addressing"> <return> <ws-a:Address>http://localhost:4040/jaxws-stateful/book</ws-a:Address> <ws-a:ReferenceParameters> <jaxws:objectId xmlns:jaxws="http://jax-ws.dev.java.net/xml/ns/" xmlns:wsa="http://www.w3.org/2005/08/addressing"> some opaque id </jaxws:objectId> </ws-a:ReferenceParameters> </return> </ns1:getProductResponse> </soap:Body> </soap:Envelope> We do something similar although our object ID is quite different (we are using a thread-safe callstack as described below). This approach can also be used in conjunction with load-balancers to maintain "sticky" conversations in a cluster in much the same way many servlet containers work as well as support fail-over for multiple callback hops. Another way I have seen conversations propagated is how Microsoft Durable Services work using service-provider tokens. In this model, they have decoupled the conversational model from how correlation is transmitted (in SOAP headers via WsHttpContextBinding, or using cookies via BasicContextBinding). With this approach, one issue is that the SCA infrastructure will have to wait for a back channel message containing the token before a second invocation is delivered. In the Java group, I outlined a fairly detailed sequence diagram of how this can be achieved in a thread-safe manner so I won't repeat it here. The method I outlined is not the most optimized, but I believe it demonstrates this can be done. The challenging part here is a potential race condition where a reference proxy is serialized and deserialized before the back channel message is received. There are ways, however, I think this can be avoided. No. IMO people should keep those types of services as loosely coupled as possible, which means generally not using conversations. However, within a domain, where both the client and provider are under the control of a common infrastructure, we have used them extensively. By bidirectional cases, do you mean conversational callbacks? If so, yes, and I think conversational callbacks are much more common that stateless callbacks. Remote garbage collection is best dealt with by a combination of: 1. Ensuring the initiating client or callback expires the conversation 2. Ensuring application components set a expiry time out (in Java, through the use of @ConversationalAttributes) 3. Providing a proprietary extension in our runtime to set default conversation timeout values. One area that has lead to some errors is failure by developers to explicitly end a conversation in application code. However, this is mitigated by doing 2 and 3. Some of our service proxies are stateful and some are not. This is determined by the scope of the client component. Yes, our service proxies can be deserialized concurrently (and we support async conversations in a safe manner as well). Yes, a composite scoped runtime instance can be part of more than one conversation at a time when we use conversational propagation (we use this pattern quite frequently). We don't have the need in our applications for a composite scoped component to act as an initiating client of a conversation but we have implemented this capability in our runtime. Actually, I generally view this pattern as a sign of a design problem in the application that can be better handled through refactoring the client to a different scope. However, there may be legitimate use-cases for this. If a composite scoped client needs to conduct two simultaneous conversations with the same service provider (I would argue this falls out of the 80% use case range), then it will need to create multiple proxies the the service. Mike R's and my proposal for simplifying the Java API we submitted a while back addresses how to do this so I won't repeat it here. Basically, we have a model where we implement a thread-safe callstack (clone on thread-association) very similar to the way OO languages are implemented that can be used in clustered environments. I think it best to discuss details on the phone if you are interested as we will need to get into very specific implementation details. We have found this addresses a lot of the thorny issues around asynchrony. As a side note, given the complexities associated with service reference serialization and my belief that it falls outside the "80% use case" yardstick, I would be happy to eliminate such capability that from the Java specification. That would simplify things greatly. However, it is worth noting that the JAX-WS RI does support this capability. For example: // ..... Cart cart1 = service.getPort(cartProvider.getCart("123"), Cart.class); W3CEndpointReference cartEpr = cartProvider.getCart("123"); ByteArrayOutputStream baos = new ByteArrayOutputStream(); cartEpr.writeTo(new StreamResult(baos)); cartEpr = new W3CEndpointReference(new StreamSource(new ByteArrayInputStream(baos.toByteArray()))); // cart1 and cart2 point to the same provider instance Cart cart2 = service.getPort(cartEpr, Cart.class); Microsoft .NET Durable services also support this capability, although I thought it best not to try and write C# given my lack of experience with it :-)
Policy is the model we are using, i.e. our support for multi-party conversations is actually implemented as an extension to our core runtime over top of our policy extension. We have a model where multiple component instances can participate in a conversation similar to the way transaction propagation works. There is not much novel about it as I believe CORBA and other distributed systems had analogous approaches to stateful contexts. To your question on conversation lifecycle, there is a set of container instances that manage component implementation instances. These containers coordinate across a distributed domain to manage conversation lifecycle. This is manageable if we assume conversations have three states: starting, in-progress, and end.
Jim
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]