[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: AW: [sdo] HelperContext material for vF2F
Most of the points we discussed in today's call (compatibility and serialization), but there were a couple I wanted to follow up on:
Starting with JAXB 2.0 users do not need to use the same JAXB implementation for class generation and runtime. The Schema-to-Java compiler produces POJOs with standard annotations based on well documented rules (a user could have also applied these annotations themselves). The annotations are then used by JAXB runtimes according to well documented rules. This was a requirement that we as a JAXB spec group needed to meet in order for us to be considered for inclusion in Java SE 6 (which we met).
There are a number of usages in JPA where the user can be agnostic of the provider and can be ported easily, there are other usages where porting is harder. JPA is expanding the number of user cases where the user can be agnostic of the provider. I'm OK with our customers believing that it is hard to switch away from our JPA implementation, but we have had a lot of success switching customers to our JPA implementation :).
Barack, Ron wrote:
7C3EF93EEBC6EB4A8B4470853DE8656674BA30@dewdfe18.wdf.sap.corp" type="cite">Hi Blaise, I'm definitely resigned to the deprecation of INSTANCE, since we all know that implementing them in a way suitible to an app server requires a bunch of really messy hacks. SDO.defaultHelperContext() is a good compromise. If I read the JAXB spec correctly, users do have to care what implementation they get at runtime: it must be the same one used to generate the POJOs. I'd be very surprised if I could take a JPA persistent object from eclipseLink and use it in another implementation. In any case, users being able to deploy to an app server without caring which SDO implementation they care seems to be a function of good source code compatibility. Anyway, the goal seems at odds with the proposal which includes a lot of mechanisms so that users that do care about the implementation can select the one they want (which is a good thing). I think in general we are on the same page about the bootstrap functionality in the new SDO class. I actually like the wording in the spec about the standard serialization algorithm, and I definitely think we should continue to define one. We define what how interop is supposed to work, but don't require implementation to use it. We should also improve the algorithm, so that non-closed graphs can also be serialized. This was also a big reason for not using the standard serialization in our implementation, we may revisit the issue when this is fixed. But I don't have any proposals yet. For instance, I'm not sure if the implementation name should also be on the stream. I differenciate betweed source code compatibility (any application using standard SDO behavior will behave the same using any implementation) and interoperability (making calls from one vendor implementation to another). I think we have a lot of work to do to achieve the first, and the second may be out of our reach for SDO 3.0. In any case, as I described, I see the default helper context as being only marginally related to the problem of (de-)serialization. In JEE, I see the defaultHelperContext as being the HelperContext that is associated with the application. In SCA terminology, it is the HelperContext associated with the contribution. And users obtain references to it using the SDO.defaultHelperContext() or whatever method. Talk to you in a few minutes. Ron -----Ursprüngliche Nachricht----- Von: Blaise Doughan [mailto:email@example.com] Gesendet: Donnerstag, 19. Februar 2009 14:59 An: Barack, Ron Cc: firstname.lastname@example.org Betreff: Re: AW: [sdo] HelperContext material for vF2F Hi Ron, Thank you for your comments. For default/global helper context my intent was to use "default" in the API. When describing HelperContexts I usually use the terms "global" and "local" when I speak, so I wanted to ensure that I defined them in my slides. Wrt your comment about having to pass around HelperContexts, are you saying that you would rather not deprecate the INSTANCE variables? Or is it enough for you to have the short cut method SDO.defaultHelperContext()? The use cases I want to see are different SDO implementations available within a single application server. Each application should be able to use a different SDO implementation. Also I would like users to be able deploy there applications to an app server without caring who the SDO provider is. This ability is a great selling point for JPA and JAXB, and SDO's inability to do this is hard to explain to customers. SDO serialization as it is today means that the same SDO implementation is available on the server and client wrt RMI. Maybe its enough to state in the spec that this a known limitation and that serialization can not be expected to work unless the both ends are provided by the same vendor, even though a vendor independent algorithm is defined in the spec. I agree that HelperContext info should be included in the serialization, do you have something that can be proposed? The "isStandard" method is meant to cover more than serialization. Users getting the default HelperContext (possibly through SDO.defaultHelperContext()), need to have some expectations on how SDO works. Currently with all the vagueness in the spec that call can hardly be recommended (different XML to property name algorithms, different handling of sequenced DataObjects and ChangeSummary). At this point I see to high level directions: 1. We focus on interoperability issues in the SDO spec. This brings us in line with the approaches taken by JPA and JAXB where there is a standard set of behaviour and vendors differentiate themselves with proprietary extras (i.e. EclipseLink JAXB offers meet-in-the-middle mapping in addition to the spec). Here users can have confidence using SDO.defaultHelperContext() and implementors wanting to vary from the spec (in core areas) can indicate their implementation is not a candidate to be the default helper context. 2. We declare that the only integration point between SDO implementations is the XML representation. In this scenario a default helper context is meaningless as the user needs to know what vendor they are using. Here I would suggest removing the defaultHelperContext methods and focusing on putting HelperContext info in the serialization info possibly as you describe. -Blaise Barack, Ron wrote:Hi Blaise, everyone, My first comments on the proposal. Perhaps, knowing what our concerns/ questions are, you can address them in your presentation... First, regarding the "globalHelperContext" (why not "default"?). I think we need this for more than just java.io.Serialization. SDO 2.0 did not require client code to pass around helper contexts, users could just use e.g., TypeHelper.INSTANCE. In 2.1 we made this HelperProvider.getDefaultContext().getTypeHelper(). Having to pass around the helper context (as a parameter in client code), is a big usability problem, in my opinion. In fact, I was going to suggest having SDO.defaultHelperContext() as a convenience method for SDO.getDefaultHelperContextFactory().getDefaultContect()... Simply to save the user the typing. I'm a little surprised by the emphasis on the multi-vendor usecase, and I'm wondering about the granularity in which the different vendor's implementations are being mixed. Of course, in a SOA application I can imagine this occuring, and even within the same VM, where for example 2 JEE applications or 2 OSGi bundles rely on different SDO implementations. I get the impression, though, that you are imagining a single JEE component, say a SessionBean, that uses 2 SDO implementations. I agree this is possible, but I think it's very much off the beaten path...not something I would put a high priority on supporting. What exactly are your usecases here? In my opinion the spec mainly provides source code compatibility, and we achieve interoperability through XML serialization. What targets do you have in mind when you say that we should give greater emphasis to interop? This relates to the reasons why I was actually against standardizing the java.io Serialization back in the 2.1 days. When a JEE application is under a heavy load and beans are passivated, serialization become a very critical operation indeed. I think it is necessary that implementations be allowed to optimize this operation as much as possible. The main motivation for standardizing the serialization format is, in my opinion, to enable RMI calls between two SDO Java implementations on different VMs. But going between VMs using RMI is relatively rare, and especially going between VMs where different vendors implementations are involved. Briefly put, my concerns about efficient EJB passivation trumped my interest in supporting the multi-vendor usecase. One is something that we do everyday, and for which we will be nailed to the wall if we don't achieve... The other is, as you guys often say, something that no user (of ours) has ever requested. Also, in our java.io.serialization, we store an identifier for the HelperContext in the stream. This is, in my opinion a required functionality. The 2.1 serialization algorithm doesn't do this, so we would have really been unable to cover all our usecases if standard serialization was a compliance requirement. The isStandard method is fine (maybe should be named something like "usesStandardSerialization"), but I wouldn't want to tie it in with what is an acceptable "GlobalHelperContext". Clients, especially EJB clients, can currently use the default context and have implicitly an efficient serialization. Requiring them to create and manage their own HelperContext would be a breaking change for us. Shouldn't HelperContextFactory also provide get methods? I'm assuming here every "create" returns a new HelperContext(). We certainly have cases where we want contexts to be shared, for instance, between instances of a SessionBean. It could be I want to look up a helper context that I've already created. I am thinking that the Map (or some special entries in the map) that is given to the create method could also be used to identify the context later. This would open the door to putting the HelperContext identifier onto the serialization stream (I think this should be part of this proposal). If we think about a JavaEE environment, what is the protection offered so that applications do not interfer with the HelperContexts of other applications? Under the circumstance that both applications are using the same SDO implementation, then they will both get the same HelperContextFactory, right? Despite whatever lookup methods we add, we need to make sure that applications cannot interfer with each other. The classpath argument to the factory create methods seems to me to relate to more than just the classpath to the static SDOs, rather, it identifies the application with which the helper context is associated. Looking forward to today's meeting, Ron -----Ursprüngliche Nachricht----- Von: Blaise Doughan [mailto:email@example.com] Gesendet: Sonntag, 15. Februar 2009 13:56 An: firstname.lastname@example.org Betreff: [sdo] HelperContext material for vF2F Hello All, Attached is some material for the HelperContext discussion. -Blaise--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]