Slashdot Mirror
Sun Releases Open Source XACML Language
LowneWulf writes "An InternetNews.com article mentions that the OASIS standards group today ratified the Extensible Access Control Markup Language 1.0 specification. But even better, Sun Microsystems Labs has backed this up with an open-source version in Java on Sourceforge."
A language doesn't need source; it's a syntax
Uh. And grammar.
Compilers need source, not languages. 'Open Source Language' sounds like more hype to me
Well open source language simply means a langauge where the compiler is OSS. It doesn't make less sense than saying "Perl is open source".
That would be a compiler/reference implementation.
A language can definitely be 'Open', but the term 'Open Source' has absolutely no meaning when attached to a language.
'Open Source English'.
That makes absolutely no sense. My point is not related to how useful or good this language is, I'm just annoyed at this example of Sun's generally confusing and strange marketing.
using namespace slashdot;
troll::post();
This seems to be a mostly server-side technology, and Java is generally accepted on the server, so I don't see it as a bad thing that it's in Java.
.NET or Java is a very negative thing, because many clients will either not have the necessary runtimes, or will have very outdated versions of them. Both .NET and Java weigh in at at least 10mb, and that will definitely hurt deployment of any technology.
However, if this technology requires the client to implement some complex authentication stuff, you've got a problem. Exclusively tying your reference implementation to 'weighty' technologies like
using namespace slashdot;
troll::post();
C is definitely not as good of a general-purpose langauge as Java is. The fact that people use it for general programming does not make it appropriate.
C is a low level language that nearly nobody understands. Sure, anyone can look at the language as a whole and think they ``get it,'' but the number of buggy C applications out there speak for its complexity.
Java is a good high-level language. Most applications need to be written in high-level languages. That means that most developers should be using high-level languages to get these things written.
C is good for writing the low-level portions of operating systems, and perhaps some embedded work.
For those who still complain about the speed of java, look to languages like ocaml and the bigloo scheme compiler. In my tests, they both produce insanely fast code (slightly slower than the C from which I translated it, faster than anything else), but are high-level languages well suited for general application development.
-- The world is watching America, and America is watching TV.
The reason they can use languages like OCaml for doing work like this is because the underlying system has already been implemented in C, and there's a regular interface for OCaml or other high level language to use. Most languages even go so far as to provide ways to use C libraries, which should show just how powerful C is.
Even so, C has some shortcomings, mostly related to many (some/a lot) of the functions in the standard library not being thread safe. A good example of this is strtok(), which isn't reentrant. The solution for fixing this was to add a function, strtok_r() that is reentrant. This works just fine, but overall isn't a good idea, because what happens next time when strtok_r won't cut it? Will strtok_r_x be added? It becomes a nightmare, because you still have to support strtok in your compiler to stay compatible with old code. C is by far the best language for programming a computer, but it's starting to pick up some baggage after 30 years of change in an industry where five years can make something obsolete (not obsolete in and of itself, just in comparison to the ``next new thing'').
The solution is a new language, written for the technology of today and backported to old computers. It would be as low level as C or lower, and have no functions that aren't reentrant. Perhaps a way of doing objects and better exception handling could be added: closer than Objective C is to C, but implemented on the next level with the new language.
As for other languages, they really don't cut it for down and dirty programming. Without a low level language, we could find ourselves in a postition similar to those people in Star Trek:TNG that had all this nice technology that nobody knew how to use. C++ really doesn't have any uses. A quote in the recent funniest nerd joke thread perfectly describes C++. Also, I have a word for people who can program Java but not C: dumbass. C is about programming a computer, Java is about using a computer.
It's a testament to C's power that it's been around for 30 years, but in that time, the way computers work hasn't changed all that much. Now they're starting to change, and adapting C to them is going to be more difficult and require clunky kludges that will eventually end in C being used like Java, rather than C used to control a computer-machine. That's why now is a great time to write a language to replace C. There are people out there with Linux kernel programming experience that know what this language needs to be, and everybody has 30 more years of experience to use to write the language.
As a bonus, if it were finished soon enough, the Hurd people would have to start over and rewrite everything in the new language.
Like so many other "XML-based" standards, XACML is horribly constrained by the lack of general logical or procedural primitives in XML. As we all know, XML is not a programming language - it was never intended to be computationally complete - yet there seem to be a neverending stream of attempts that effectively try to turn it into one.
It is a fundamental mistake to try to shoehorn semantics which will generally include logic - such as an access control decision - into a language which has no support for them. While XACML "is not intended to form the basis of an authorization decision by itself" it must of necessity include the means to combine and modify rules - hence requiring logical operators which of course have no standard representation in XML.
The specific result is that each attempt to use XML for anything other than the simplest semantics (SOAP, Schema, XSLT, JSP...) must invent its own representations of operators, variables, modules and so forth.
The general result is one unholy mess. We, the poor bloody coding infantry, have to face learning a dozen or more ways of representing the same fundamental concept in a multitude of languages, each supposedly specialized for a narrowly-defined task, but in reality incorporating almost-but-not-quite-all the features of a general purpose language. XML's ugly syntax becomes the least of our problems - that can always be hidden by visual tools or 'generators', but no tool is likely to be able to reunite fundamental concepts fragmented into so many different representations.
Standards such as these do not represent progress, they represent a growing mass of redundancy that one day will have to be refactored into more coherent form. Anyone who studied LISP, or some other language capable of representing the popular data and programming paradigms (logic, procedural, declarative...) will be aware that common ways of representing such semantics have been known for decades. The fact that the practice of XML continues to ignore such basic prior art is an extraordinary indictment of the state of our industry today.
I welcome any explanation from the individuals or organizations concerned as to what obliged them to make yet another idiosyncratic elaboration of the generally incoherent and unusable body of XML specifications.
This is really a bit of a niche domain (in that, system administrators and other folks are interested, most other people aren't).
Basically, in the world, there are many scenarios where it would be VERY useful to be able to enable access controls on various resources in a system. By "access controls", I mean rules which define who can perform actions on given resources. This sounds so general because it is very general. The purpose of XACML is to provide a language which allows you to specify these rules, or policies, in a nice format independant of the rest of the system (data storage, etc) for any number of domains, and provides software to implement the required components for such a system.
As a solid example, you could use XACML, a central PDP, and a PEP on a set of firewalls to control which IPs have access to what. You'd have to write a PEP for the firewalls, and set up a PDP to handle the requests, but once this is done, you could use XACML to write firewall rules!
Another example, suppose you have a user trying to access their email. You could have a PEP in the client which talks to a PDP to determine if the user is allowed to perform various actions on the mailbox (read, write, etc). In this case, you'd use XACML to determine who can perform what actions on the mailbox.
In both of these cases, XACML defines the language PEPs use to talk to PDPs, and also specifies a common XML language for defining the policies to determine who can do what.
In essence, XACML abstracts these concepts of policy enforcement, rule definitions, etc, and wraps them up in a nice XML language which can be used in any component which implements the XACML specificiations for a PDP and PEP. Why would you want to do this? Well, first, it allows you to use plug in in an access control system, rather than having to roll your own. This is good. Second, anyone who implements the XACML standard can interwork. So, I can write a PEP for my email client, and use Joe's PDP to enforce policy in my system. Third, because all your systems now use a single language, you can centralize the policy database and use common tools to manage all of them. An administrators dream!
Now, this is really important people, this has NOTHING TO DO WITH DRM! Or Palladium! Or any other conspiracy theory you want to come up with. This is simply a tool for software developers and system administrators to easily integrate a standard access control framework into their systems.
* Note, in the previous, PDP - Policy Decision Point, and PEP - Policy Enforcement Point.
One of the beauties of XML is so many different language bindings exist.
That XML is a lingua franca is frequently asserted but can't be proved. The reason is that XML has no (or more strictly, very limited) semantics.
To say that your application can "understand" XML because it can use the DOM API doesn't mean that it can interpret XACML, or any other XML "ontology". You might just as well argue that you can understand Danish because you can parse the "å" character.
All you are saying when you assert that XML applications can be written in any language is that the semantics of XACML (or whatever) can be mapped to various programming languages.
This feature is shared by any machine-readable language, many of which are arguably better at representing XACML semantics than XML.
Also, I have a word for people who can program Java but not C: dumbass. C is about programming a computer, Java is about using a computer.
If C is the only language you can write in, then every further word is wasted I guess.
Anyway:
The solution is a new language, written for the technology of today and backported to old computers. It would be as low level as C or lower, and have no functions that aren't reentrant. Perhaps a way of doing objects and better exception handling could be added: closer than Objective C is to C, but implemented on the next level with the new language.
Probably you might look at 'D', the language Walther Bright is working on? See www.digitalmars.com.
C might be an appropriated language for system programming, but that is more or less a shortcomming of our current computer architecture, not a feature of the language C.
Two simple 2 liners like:
int i = 4;
fwrite(FILE, &i, size_of(i), 1);
and
int i;
fread(FILE, &i, size_of(i), 1);
Thats not even portable over different system architectures. And sometimes not even over two different compilers on the same architecture.
If everything looks like a register or like memory your appropriated tool is
But if your problem is not register or memory and not signal processing
Neither is Java, but we have nothing wich is better
At least a Java program or a server component running on an App Server is portable.
And Java offers hundreds of APIs, STANDARDS even, to cope with all cross architecture interoparability problems.
If you would say, PERL, ok, then I only could say: puh, a nerd, writing in a cryptic 'write once, never maintane' language.
But PERL indeed offers nearly everything Java offers. Easy web integration, DB access, portability, speed, text and XML processing etc.
But C?
BTW: writing a linux like kernal is to be done far easyer in Java then in C/C++.
Your post simply shows that you have no clue about Java and that you think you have a clue about C
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.