|
|
Re: Going all in...
|
Posted: May 19, 2005 2:51 AM
|
|
> > Exactly, and that's why passing well modeled data
> around
> > is preferable whenever there is no central control over
> > deployment, versioning, etc or when it simply gets too
> > complex to manage and you need more flexiblity or when
> you
> > want to build systems in a way that is amenable to
> > integration with other systems in the future.
>
> I don't consider the structure of that data any different
> than
> the serializable form of a Java Object. In either case,
> you
> can be in control, completely.
We're talking in circles. I never said you couldn't be in control of serialisation. But when you are in control you need to have the right tools and abstractions to describe and manage the wire representation. Java and RMI don't help me with that in any way, whereas XML web services provide a set of languages and rules for exactly this purpose.
> In the case of XML, you are locked into no dynamic
> granularity
> control that mobile code gives you. Once you decide on
> XML,
> changing to something different is pretty much impossible
> because every single user is dependant on that format.
Well, let's be clear: No matter what technology you use, there will always be something you commit to, that you cannot simply rip out and replace. The question is how broad this commitment is. It's no different when you invent your very own serialisation format. The reason why XML is so popular for interop is exactly because the commitment is very small. It doesn't determine the programming language, the runtime or particular runtime versions and it carries a lot of metadata which makes versioning very flexible and granular. It doesn't even mandate a particular programming style like RPC or OO, you can do messaging as well, store and forward, etc. It's easy for any system to send and receive text over some network. Much easier than to embed a Java virtual machine and comply with the fluffy notion of an "interface" that Java offers.
> If
> you need to compress the stream, everyone has to take
> that
> into account.
No, not at all. It's a question of protocol design to have a way of negotiating the capabilities of sender and receiver. HTTP does exactly that with its various accept headers.
> > Yes, more or less. The important thing is that they can
> > agree on a meta model that allows you to define which
> > particular parts of the data must be understood, which
> > ones are respected if supplied, how other parts are
> > ignored, and so on. If done right, there can be a lot
> of
> > flexibility in that agreement.
>
> Yes, this is possible, but look at all the places that
> those agreements can break either on purpose of by
> oversight. All of this procedural based contract
> enforcement is not a very safe way to manage important
> contracts.
How is this "procedural based"? It's a declarative formal contract. You can mandate and describe a lot of things that you cannot describe formally in a Java interface.
> In Jini2.0, there are several tools which solve a lot of
> problems.
>
> o Dynamic Proxy support in JDK1.4 and later, no RMIC.
> o DynamicPolicy support to handle dynamic security
> needs.
> o Kerberos and X.5XX transport for authentication and
> mutual identity establishment.
> o A plugable transport stack (JERI) that allows you to
> talk whatever wire protocol you want so that you
> can plug into SOAP or some other invocation layer.
>
> > I totally agree that
> > these are not fundamental logical problems at all and
> one
> > should think that there's a better way to do it. But
> > again, this industry has been trying to do it for many
> > years and so far it always failed. Even if you limit
> > interop to the Java only.
>
> I guess that one industry may be having problems. I hear
> alot of horror stories from J2EE users. I've heard of
> many
> large Jini applications. Secure interworking was not
> possible until the security layer added in Jini2.0. It's
> still possible for trusted code that is downloaded to do
> things in your JVM that you might not find acceptable.
> It is now possible to validate the source and version
> of the downloaded code as well as the calling party for
> initial deserialization attack protection.
So does Jini find out dynamically which J2SE versions and which versions of particular third party libraries are present in a particular deployment and download the rest? And is this done in a way that doesn't conflict with the set of libraries and J2SE versions deployed by a different service provider my systems relies on?
> I think we'll have to agree to disagree. Integration
> only
> gets more difficult because we continue to diversify on
> the
> runtime environment.
The only way to solve integration problems is by reducing coupling. You will never be able to mandate a completely homogenous environment. And that's not just because one group uses Java and another one .NET and yet others Perl, PHP, Oracle PL/SQL, etc. It's also because each particular platform and each particular application has its own versioning cycles. You can't force them all into lockstep. It's not a matter of choice whether we have diverse IT environments, it's just a fact of life.
> > Well, first of all it means that mobile code is not
> viable
> > on the Java platform today. At least not across
> > organisational borders. But I think there is a more
> > fundamental reason for these practical issues. It is
> very
> > hard indeed to make something like J2SE forward
> > compatible. Forward compatibility is hard with data
> > formats and almost impossible with large collections of
> > procedural code. And it is even harder in statically
> > compiled languages.
>
> I guess I'm not seeing the difference. Bytes of data
> flowing
> over the network, no matter what the format have to
> arrive
> in some predictable representation. Regardless of that
> structure, changes in the format are problematic from a
> general perspective.
No, I'm afraid you're totally wrong in this case. Different representations have different logical properties. The semantics of procedural code can only be established by means of flow analysis, which is infinitely harder than dealing with declarative data or rules. It is quite often logically impossible to find out if two pieces of procedural code have the same effect for the same input, without running it. And running it, is exactly what you cannot do before finding out if you have compatible version or not.
> Java Serialization takes care of
> announcing incompatibility quite literally through
> serialVersionUID. An XML document could do this with a
> DTD assertion. But, most people don't seem to be doing
> this based on what I've seen/heard.
That's because XML has more granular ways of dealing with versioning than just success or fail based on a version flag.
> In either the case of serialized Java Objects or XML you
> can, by mistake, break the format of the data for other
> users. There is no protection against this. So, I don't
> see how a printable text representation of "data" is any
> better than a binary representation. In either case it
> can either be right or wrong, usuable or unusable.
It's not about text versus binary, that's another debate. But as I said, different representations have different logical properties. One representation may allow me to make declarative assertions about what I require, what I recognise, what I reject and another representation wouldn't allow me to do that. You can't just ignore the logic and think of everything in terms of blobs. There are some properties you really want to have in a representation. One is that you need to be able to judge the semantic equality of two lexically different expressions. So you need a deterministic algorithm that produces a canonical representation that can be compared. If you encode rules in a sequence of procedural steps and you have variables that are manipulated along the way, you are very likely to end up in a situation where canonicalisation is logically impossible.
And since Java's type system is so weak, you have to write procedural rules for things that you assert declaratively in other languages like XML Schema or RELAX-NG or OWL. The consequence is that Java code cannot be analysed for version compatibility. You have to set that "make or break" compatibility flag (serialVersionUID) manually for the whole class. There's no way of judging a particular incoming request based on the data that it carries and decide if you can deal with it or not. And there is no way of communicating these rules to others so they can automatically validate their messages or implementations. But that's exactly what you need in a loosely coupled system.
> With Serialization, you can version the objects and
> manage
> changes in the structure of the transported data. You
> may
> not have ever implemented such support in your
> serialization
> schemes, but it is possible. You can do [...]
I know that, and I said many times, that you can manage your serialisation format. But Java doesn't help you to do that. There is no schema language to declaratively state rules about that format and there is no standard for describing the technical metadata of a service in a way similar to SOAP/WSDL. You can invent your own serialisation format and your own processing rules and so forth, and then you communicate them to each and every partner you want to interact with.
But you know, I see a contradiction in your argument: On the one hand you stress that you can manage serialisation, but on the other you tell me that it is not necessary to do so, because you can send mobile code everywhere anyway. The thing is this: If you manage the wire format, you do it because _other_ people depend on it and _they_ have to manage their side of the system. You are absolutely right, that this is not necessary if their side doesn't depend on the wire format because you send them a proxy that manages communications to your service.
> It's the whole business of correctly manage the
> serialized
> objects lifecycles that needs to be correctly designed.
Sure, I don't deny the value of this at all. You just have to recognise what it can and cannot do with blobs of downloadable code. It has logical limits (as I explained above) and above all, it has organisational limits because you mandate a homogenous IT environment that you rarely have.
> > OK, you're right, changing the order alone is not
> enough
> > break it. But the point is that there is no separation
> > between logical and purely technical changes that
> > shouldn't cause version breakage. The default
> > serialization leaks implementation details. You cannot
> > change the private implementation without risking to
> break
> > compatibility, which is the whole point of
> encapsulation.
> > I think to make it work in a robust way, you have to
> > manage the serialization format, one way or another.
>
> The serialVersionUID changes when you add an instance
> variable, add a method, or change the signature of an
> existing method.
Sure, but the problem is that you have no clear separation of interface and implementation. If you change a data structure inside your implementation, you break the serial version without there being a logical necessity. That makes the whole system brittle. The only way of managing it is putting only relatively simple value objects in your interfaces, but then you lose any benefit of sending Java objecs in the first place.
> > > I've been using RMI for rpc and integration since
> jdk1.3
> > > (I used Voyager in JDK1.X, and never used JDK1.2 due
> to
> > > its bugs). I've never had a JVM dependency problem.
> > > Perhaps my usage patterns eluded the issues that you
> have
> > > e experience with?
> >
> > The question is simply whether you are completely in
> > charge of the deployment environment and whether you
> are
> > integrating your own applications.
>
> I don't have a problem with premise of this statement.
> However I do think its important to identify what makes
> integration possible. It's only through common use and
> knowledge of some underlying transport and data
> formatting
> that you can make two disparately located systems talk
> to each other. XML is one data format and HTTP is one
> transport technology. Neither has any technical
> advantage
> over other documented data formats and transport
> technologies.
I think I have expressed my opinion about the advantages of data based integration. To sum it up: Uncoupling of interface contract and implementation. Uncoupling of runtime environments and their particular versions. Flexible handling of message schema evolution based on widely used standards.
> Practically, there are toolsets and hardware technologies
> that provide assistance to XML deployments in some
> situations.
> It seems like this will likely be more common rather than
> less common in the future. ESB is another layer that is
> said
> to be needed because of features that don't exist in the
> area of XML based services.
So far I wasn't aware that ESB is anything more than a marketing term. What are the characteristics of ESB that contradict data based protocols?
> > I don't call it
> > integration when I simply want to make two of my own
> > applications maybe even client and server of one
> > application talk to each other. That's not integration.
> > Integration is making applications written by different
> > people, without central coordination, talk to each
> other
> > and share information. I cannot download mobile Java
> code
> > into other people's applications.
>
> Integration, to me, is taking previously disparate
> applications and making them work together to create
> a new application that provides something previously
> not possible. If I get to do this locally, that isn't
> necessarily any easier than if I have to do it with
> someone elses code.
Of course it is much easier if you can just go in and rewrite parts of the application in a language/runtime of your choice than having to integrate applications written by others.
> > Even if all applications
> > on the planet were written in Java, you'd need to
> rewrite
> > them all based on a completely different architecure
> > (maybe like Jini?).
>
> I think this is the ultimate question. Is it easier and
> cheaper, in the long run, to continue supporting multiple
> languages and multiple platforms, or is a single platform
> and/or language a better choice?
This is one of the important questions, yes. Another one would be the logic of describing interfaces, separating interface contracts from implementations, and if it is advisable to hide business rules in procedural code. But the problem with your question is, in my opinion, that no matter how you answer it, the world will not comply.
I would even think that it'd be horrible if it would comply because there would not be any progress. When I think back to 1996, when I first used Java in a large scale project, the context was something like AS400, RPG, VB, VC++/MFC/COM, Tuxedo, Delphi, Oracle PL/SQL, just to name a few of the things that our prospective customers were using. There was no homogenous environment and if we had decided we wanted to deploy mobile code into these systems, we would've had to hire an army, topple the government, nationalise all the banks and force them at gun point to reimplement everything in Java.
> I believe that software vendors are moving toward the
> one platform notion. Microsoft's CLR provides a single
> set of primatives expressed in multiple languages, which
> are restricted by the intersection of the features of
> those languages. The Java language and the J2?E
> platforms
> provide a fairly common set of features with J2EE and
> J2ME
> restricting what J2SE features you can use to provide
> a container that is targeted at solutions for specific
> types of problem solving.
>
> Sun has met with the dynamic language creators for Perl,
> Python, and others to see what they might do to the JVM
> to allow it to support these languages natively.
>
> Unification is happening. There is value in it, much
> beyond the simple comforts that "choice" brings to some
> people who want to make decisions independently.
>
> I think that if you don't see this coming, you might
> be horribly surprised when your competition is suddenly
> based on a highly portable and featureful platform that
> provides them a lot more choices than your choice does
> you.
I agree with you that more and more code is built on top of hardware platform independent virtual machines. But as in the past, there are a number of them, some linked to a particular OS, and over time you have to deal with a large number of versions of each of them. You have at least 4 technology stacks right now that don't run each other's code and I don't see them converging any time soon. But this is not only about compatibility on VM level, it's also about the frameworks on top of them. An EJB doesn't run as a Jini service or vice versa (without jumping through some hoops). Every day new frameworks come along with their particular APIs and depending on what services a piece of code needs, it has to make use of these APIs to some degree. Yes we are somewhat less hardware dependent than 10 years ago, but overall there is more heterogeneity not less.
|
|
Previous Topic
