Slashdot Mirror

I guess you meant CORBA, and no, even if OSS was an entity (perhaps you meant OSI) it is far from abandoned.

OMG, I totally read the same thing.

Yes, it is exists and it's called CORBA http://www.omg.org/ . In particular, omniORB http://omniorb.sourceforge.net/ is VERY fast. The only thing is that it's not a "Web service" and doesn't use HTTP.

FireStar Software, Inc. .. today announced a go-to-market agreement with Microsoft,

Mark Eisner, CTO, FireStar .. has been a consultant to .. Microsoft ..

Interestingly, I had just run across these yesterday--note these used OpenSS7 implementation and call out issues w/LKSCTP mentioned in other posts:

http://www.atl.external.lmco.com/projects/QoS/docu ments/DOA2003_97_Thaker.pdf

Seems the funding for the TAO SCIOP implmementation came from the US Navy:

http://www.omg.org/news/meetings/workshops/RT_2003 _Manual/Presentations/5-4_Thaker_etal.pdf

You are right, MDA certainly appears to encourage this strategy. However, I don't think anyone using a graphical interface to build an application can actually work with this write/draw, compile, verify strategy without risking big time failure.

And that's the point. MDA is perceived as something which makes the task of developing software easier. It doesn't,it just takes away some of the grudge work (i.e. coding standard blocks).

I quote from a technical whitepaper found here :

Today, process of application system development starts with business owners zero in on idea followed by marathon meeting with IT specialists end result being business owners/Managers are left grappling with some incomprehensible technical documentation and not with a tangible solution.

Great! Tell managers to buy and use MDA so they don't have to put up with these pathetic "computer experts" any longer! They can just go ahead and "design" their own business software, it has become so easy now!

Or look at the following quote from this source:

The required skill set and the depth of technical knowledge is reduced, which lowers labor costs.

The idea is to save an expensive software team and exactly that leads to the failures people experienced with MDA (or any new technology that was supposed to make life so much easier). Those vendors sell their software to PHBs who then let their "business solution" be written by code monkeys who are not only unable to complete the task but don't even realize they never had a chance with their skill set (But they offered it for almost no money, so they got the contract!).

You are right, MDA certainly appears to encourage this strategy. However, I don't think anyone using a graphical interface to build an application can actually work with this write/draw, compile, verify strategy without risking big time failure.

And that's the point. MDA is perceived as something which makes the task of developing software easier. It doesn't,it just takes away some of the grudge work (i.e. coding standard blocks).

I quote from a technical whitepaper found here :

Today, process of application system development starts with business owners zero in on idea followed by marathon meeting with IT specialists end result being business owners/Managers are left grappling with some incomprehensible technical documentation and not with a tangible solution.

Great! Tell managers to buy and use MDA so they don't have to put up with these pathetic "computer experts" any longer! They can just go ahead and "design" their own business software, it has become so easy now!

Or look at the following quote from this source:

The required skill set and the depth of technical knowledge is reduced, which lowers labor costs.

The idea is to save an expensive software team and exactly that leads to the failures people experienced with MDA (or any new technology that was supposed to make life so much easier). Those vendors sell their software to PHBs who then let their "business solution" be written by code monkeys who are not only unable to complete the task but don't even realize they never had a chance with their skill set (But they offered it for almost no money, so they got the contract!).

PS. Good alternative to CORBA is ICE (http://www.zeroc.com/ice.html), which is basically the same thing as CORBA, and founded by one of the CORBA gurus. ICE has much better C++ mapping, and lots of other nice features.

Hope this helps!

With this topic, I expected discussions on such technologies as MDSD, MDA, or AOP yet there is no mention of these here. Does everyone here consider them to be DOA?

It's XMI not XML.
http://www.omg.org/technology/documents/formal/xmi .htm

http://www.omg.org/technology/documents/formal/dat a_distribution.htm

Data Distribution Service.

Like OMG or not, it is open, and you can build it (there is an open source project started on source forge with no activity yet), and it is an adopted standard. It supports "queueing" via a number of different QoS parameters.

I haven't read the spec on AMQ, but I'll make a wager that DDS is more powerful, and has more features..plus it can be built for embedded systems, as well as the Enterprise.

There are a number of commercial implementations of the spec to be released very soon.

Okay...I'm not completely up in the inner workings of GRID computing, but is the premise the same as those used in the past for other distributed environments such as DCE (Distributed Computing Environment ) or CORBA (Common Object Request Broker Architecture)?

My experience with DCE at least was that it was a distributed environment that took a lot of coordination between systems, which unfortunately was not done very well in the environment I'm familiar with. As a result of this it did not prove robust enough for the systems it was used for. It had some possibilities, but if not done properly, can be a major confusing thing to deal with.

With CORBA, as I understand it (I've never directly worked with CORBA), it is suppose to represent similar services in a more Object Oriented way and easier to program with. Not an expert, but I believe this is ingrained into Java world along with other RMI type interfaces or peer to peer intefaces (like JXTA).

With these types of services, both DCE and CORBA offer distributed network services such as directory services, distributed file systems, and security services on hetrogenious environements. The interfaces are defined (see IDL) and compiled in to stubs for client/server services to develope and use on any compatible platform.

How is GRID different from these methods?

/greger

At my school, they teach the students to use UML.

The Unified Modeling Language.

Start Here, then try google for more introductory articles that are out there.

If you want books on the topic, I recommend UML Distilled by Martin Fowler for a quick intro, then branch out from there. (There's hte Object Technology series from Addison-Wesley, which are usually very good, but they're not the only UML books out there) I also recommend you download a UML tool (there are a bunch out there - free as in beer, Open Source, or try a commercial trial version)

As for flowcharting, there are several model types in UML to handle it. Activity diagrams come immediately to mind (these are very close to the classic flowcharting techniques), but state charts and sequence diagrams are useful also to supplement an activity chart. Also look into the structural models - class diagrams, deployment charts, etc. when assembling/designing your program.

UML is language independent - meaning it's not explicitly tied down to one specific language. Although, it is useful to keep in mind what language you plan on using when authoring in UML.

With version 2.0, UML is going to make an enormous step towards visual application design. Several ambiguities are resolved. Class diagrams and OCL are now built on precise foundations (set theory and predicate logics) [1] -- instead of having most of the semantics described in plain English; the fundations of other diagram types were also formalized.

The advantages of more precise models are that they can better form the basis for code generation [2] or even direct interpretation [3,4]. In contrast to earlier approaches to code generation, a common standard now allows interchange between different tools (at least to some extent).

Here, one of the main advantages is probably not "point and click", but a higher level of abstraction: current programming languages simply do not support high level diagram elements--such as bidirectional associations--as first class members. Things that can be expressed by simple means in class diagrams and OCL expressions become multi-line code in a regular programming languages[5]. Of course, building on UML directly also may resolve maintenance problems such as inconsistencies between diagrams and the actual code.

1. http://www.amazon.de/exec/obidos/ASIN/3897228424
2. http://www.omg.org/mda/
3. http://www.riehle.org/computer-science/research/20 01/oopsla-2001.html
4. http://www-ai.cs.uni-dortmund.de/auto?self=$dq74rv vv
5. http://i11www.ilkd.uni-karlsruhe.de/~baar/oclworks hopUml03/papers/10_combined_model_processing.pdf

Perhaps you find this article interesting: "A New Approach to Object-Oriented Middleware". This article appeared in the IEEE Internet Computing magazine, and compares Ice with CORBA.

LOL, we wish everyone an Xtreme New Year from Slashdot, OMG.

What does Object Management Group, the maintainer of the CORBA standard, have to do with anything?

It has been a long time for me, but CORBA might fit the bill.

Unfortunately, this kind of thing still starts in the military world. The DoD has been developing requirements for Network Centric Warfare (NCW). Basically turning warfare interfaces into a RTS game like StarCraft, C&C, complete with fog-of-war, semi-autonomous units, comm & data sharing, etc. On the technical side, this is manifesting itself as Command, Control, Communications, Computer, Intelligence, Surveillance and Reconnaissance (C4ISR) architecture. One of the first actual implementations is being worked in in the form of Future Combat Systems (FCS).

These are complex systems, so the DoD has been maturing development of modeling & simulation interoperability by making contractors adhere to High Level Architecture (HLA) so they can properly analyze these systems before deploying them. HLA basically provides a lot of the same data object registration, distribution, and interfaces that older tech like CORBA does, with extra simulation concepts.

These technologies are being commercialized under the buzzwords "Nework Centric Operations" (NCO) and "Network Enabled Operations" (NEO). Advocates usually point to well networked operations like Wal-mart, UPS, et al. as poster children for what could be done (automatic restocking, package tracking, load balancing & route optimization, etc.) with enough NEO infrastructure. A lot of the interchange standards (including C4ISR) are getting established through bodies like the OMG. Other than the interchange standards, there's not all that much new tech involved... maybe RFIDs and various other networking tech (grid/mesh networks, strong encryption/authentication, mobile IP, etc.). Most if it just involves looking at technology that already exists and figuring out how to piece it together to actually do something worthwhile.

Disclaimer: I work for one of the gov't contractors throwing all these buzzwords around.

that's not what i've talked about. still i think that gnome focuses on widespread compatibility, more so than kde does.

corba is a widely accepted standard for developing distributed componenents, which include desktop components. a lot of developers that know and use corba can easily adapt to orbit.

same goes for the signal/slot design. i appreciate the way the qt c++ extension integrate into the language, but why develop another preprocessor when there are macros and templates? that adds a dependency to the qt tools (i.e. moc).

by the way, that is exactly what icaza's mono project is about - language independent = maximum compatibility. i like that general focus in the gnome project.

And abstraction is the fundamental means of reducing complexity.
The history of programming is the movement from physically inserting patch cables to program a computer to manipulating abstractions. In languages like C, those abstractions are still pretty close to the hardware; in OO languages they tend to be closer to the problem domain. Edsger Dijkstra once said that software development was unique as a profession because it required practitioners to operate at 7 levels of abstraction - from transistor to algorithm to software architecture to business domain. Of course, very few of us deal with "transistor-level" programming these days.
So, Simonyi's "intentional" programming is part of this broad sweep of improvement in programming languages in the last 50 or so years. The current emphasis behind Model-driven architecture is a similar desire to somehow take away all that messy code stuff and replace it with nice, easy to understand pictures.

The problem with both these approaches is that complexity exists inherently in the problem domain. The role of a software development team is to chose a path through that complex problem domain and implement it with working code. Right now, I don't believe we have tools which are sufficiently expressive and intuitive to model the complexity of the problem domain, and we must be years if not decades away from being able to convert such models to working code.
UML is lovely - it's a great language for expressing software ideas and conveying a lot of information in a graphical format, but the average business user just does not get it; in my experience they are primarily useful for communicating between developers.
Use cases (in textual form) are far more useful for communicating with business users, but to convert a usecase into a working program would require natural language parsing at a level that must be a generation away.

We should wish Simonyi luck - his ambitions are worthy, and will benefit all working developers if they bear fruit. And what better use to put a couple of billion dollars to ?

Query results are actually .NET objects,

• .NET? Nooo, that's too proprietory!
• J2EE? Nooo, that's too complex!

"Try that in Java. Try any cross language development in Java."

It wouldn't be another day at Slashdot without misinformation...

Click here please.

"Even though Java's done it for a long time, you're tied to one language"

You might look into CORBA before you go making such claims.

No, it stands for Object Management Group (the people who came up with CORBA).

I read recently that there is a prion disease where you suffer months of insomnia before dying a slow, agonizing death from neural degeneration. So make sure you bookmark that link. If you ever get that disease, you'll want to print out some OMG standards documents and force yourself to read them. It could save your life someday.

The MDA defines an approach to IT system specification that separates
the specification of system functionality from the specification of the
implementation of that functionality on a specific technology platform.

To this end, the MDA defines an architecture for models that provides a
set of guidelines for structuring specifications expressed as models.

I believe that we really need a standard for arbitrary abstract data models, with XML as just one syntactic representation, but I would have to go into long details to justify this.

You mean XMI? (XMI = the XML serialization of the OMG MOF, which is the meta-metamodel for the UML metamodel? The MOF is its own metamodel so you stop there BTW)

Oooh yeah, bring the complexity baby! If you thought working with XML was bad just take a look at that stuff. And weep. Its XML Schema on steroids.

Unfortunately XML alone doesn't guarantee data interchangeability between programs. And XML Schema doesn't do it either. Knowing whether or not Tag1 can be in Tag2 doesn't tell you what Tag1 or Tag2 mean or if they correspond to a data structure that you need or can use. For that you need data modeling.

For data modeling in XML I've looked at a huge number of languages: RDF, Iso step 28, and XMI were my favorites (though in my opinion XMI first starts getting interesting with ver. 2.0 which isn't even finished yet). Each has a few advantages and disadvantages. And of course there are lot more than just these. But the problem is that these are all very young standards and APIs which would make them useful are not abundant.

So maybe the author's right that XML is not yet good enough, but I think a lot of progress is being made.

What do the maintainers of CORBA technology have to do with anything?

s/SVG/XMI/

most CASE tools these days can import/export XMI (to varying degrees of interoperability). XMI is an XML serialization of the model the UML diagrams represent. These days you can use most Rose to draw a model to be implemented in a language it doesnt support, save it as XMI, and generate code by transforming the it. Beats trying to parse Rose's petal files.

If you just want to draw pictures, Rose is far too much baggage. If you want to use the pictures as the basis for something else, then SVG is not enough.

-Baz

Every conforming ORB must implement IIOP (GIOP over TCP). Interoperability between ten major ORBs was tested and documented three years ago. If your vendor can't even handle that, they have little chance of getting Schema right.

.NET is the most exciting thing in distributed component programming since Objective-C and NeXT

Oh, please! .NET is nothing that hasn't been done before, and it's missing a lot of stuff that other distributed systems have had forever.

SUN RPC has been around forever. CORBA has been around for a long time. Both SUN RPC and CORBA use a binary on-the-wire format for efficiency. .NET uses high-overhead XML for everything. Both SUN RPC and CORBA allow for operations on objects, where SOAP only allows static functions (Why's the 'O' in SOAP anyway?!).

.NET is an exercise in marketing and leveraging a monopoly. There's no new technology here.

Q: Why use reinvented tools for reinvented tasks?
A: To reinvent the solution!

Makes perfect sense to me. If you are wondering, XML is nothing more than flawed S-expressions and Java is a reinvention of a P-code interpreter. Combine the two and you have more reinvention. All paths lead back to the future...

Writing software is not difficult. Writing high-quality software _is_ difficult and requires experienced craftsmen (infer journalistic gender-neutrality, please).

So how then, can you get high-quality software quickly? Two ways:

1. Hire experienced experts. Experienced experts produce high-quality work quickly. They write code generators to do tedious work for them. They classify problems and hunt down and implement reusable solutions. Keep giving them raises and interesting problems. Granted, defects in the software will be of the extremely intractable variety (very subtle design flaws or bad/wrong requirements)
2. Reuse experienced expert knowledge and technique in the form of pattern-driven code generating tools. Hire journeyman developers to adapt the code the tool burps out and get on with life. Keep an expert or two around to extend or correct the patterns the tool uses for generation. You'll get applications that are far less pretty than the hand-crafted variety. On the other hand, the defects are known and predicatable. Tools (apologies for the shameles plug) for this sort of development are just now becoming available and practical. Granted, when handed a powerful implement fools often find a way to hurt themselves (thus instantiating the 8th corollary to Murphy's Law).

Either method has drawbacks. #1 produces the best software, #2 produces the cheapest software. #1 makes the "Agile" crowd happy while #2 is the sermon of "Software Engineers."

Why single-out developers for defective code? Because developers write defective code. No, all developers aren't clods with text editors. Developers who do write buggy code may even care about their craft (Pragmatic Programmer tip #1). But developers themselves are to blame for the defects in their work, even though outside factors contribute to problems. We must take responsibilty for our bugs, move on and fix them. Then find new ways of working that make it more difficult for software defects to make it into production evironments.

We cannot fix imperfect programmers. We can only mitigate the effects of their imperfection through mentoring, certification, education, and proper management. In other words, treat software development as a craft, a talent to be polished and perfected.

Writing software well means communicating well with a computer. Artful written communication is very difficult to reduce to an engineering discipline, yet the skill can be taught and practiced.

For big projects (and only big projects) using the Unified Modelling Language and especially the Rational Unified Process is very useful.

Rational has quite a few tools which (when used correctly) allow to trace what class is responsible for which business case.

As far as WSDL is concerned, have you ever seen it? It's the most confusing, ill-designed, vague document on the planet. Many people have mentioned that XMI (XML Metadata Interchange) is far more suited to description of software objects, and would be far better for publishing/discovering web services. It's the format for UML, after all. It's here.

As far as SOAP extensions are concerned, any programmer that has needed to distribute software knows that you should always adhere to the core standards when designing your application. The use of any extension, or any veering too far to the left or right, will make your application unportable.

So let them have their members-only club, with a membership of 2.

I've got no love of UML, but when I did have to use it I found the UML specs themselves to be quite good. I used version 1.3 but the latest (1.4) look like they are out. A simple introductory book (like the one by Martin Fowler) and this baby should see you right. It would also be nice if the specs. were better indexed, and more easily searchable.

The XML Metadata Interchange (XMI) standard was agreed on in 99, I believe, and allows various UML tools to share diagrams. As you mentioned: It's in XML, though anything could be represented in XML.

My 2 kopins worth

Any idiot with a sufficiently powerful transmitter can DOS a scientific LEOsat while in the footprint, with less than a thousand bucks of hardware.

For the info of /.ers most LEOsats adjust their attitude with magnetorquers and reaction wheels, they are incapable of changing their orbits even if you snatch control. But you can, over successive orbits, put them into power-draining modes that will cause eventual loss of the bird.

LEOsats are also only commandable from one groundstation for 1-2 slots of 15mins or so per day.

Many scientific satellites use the ESA PUS standard high-level protocol (PPT here) on an AVTEC box or something similar, using CCSDS. It would be trivial to "crack" (since it's not encrypted), given a hundred thousand bucks for the hardware.ROT-13 is harder.

In summary, any moron can make life difficult for researchers. But firebombing chemistry pr CompSci labs would be just as "clever", far easier and cheaper, and even more annoying.

BTW unlike some who think this is a troll, I'm concerned about the issue myself. But given the hardware cost of implementing a reliable CCSDS protocol, only fairly wealthy hackers could do it. The Software is relatively easy for real-time programmers, but script kiddies, VB-jocks or even C coders need not apply, Ada would be the best way to do it with assembler second. The additional security of adding encryption on top would be negligible, as wealthy hackers could be expected to have access (hacked or legit) to arbitrarily large amounts of computing power. And any script kiddie could DOS us with a five-hundred-dollar jammer anyway. For 15 minutes.

Alright, maybe I posted a little too soon, but shouldn't "flamebait" be attracting flaming responses? I don't see any...

Anyway, if I'd spent a little more time thinking about the advice side of it, taking a look at appropriate programming methodologies (like Extreme Programming advocated in another thread here) would be one piece I'd advocate. Given the size of the code (1 MB = about 20-30,000 lines?) there's no need for major heavy-weight processes here. More important I'd say is sitting down and figuring out in the appropriate level of detail what exactly your system is doing right now - you can do this using UML diagrams which seems to be becoming a standard, though the main use we've found is to try to get an overall view of things which we then throw out when we get into the details again.

The other thing to do along these lines is look for your use of standard patterns within your code - the Design Patterns book is extremely helpful if you're moving to an object-oriented framework at all; following well-known patterns and indicating clearly what you are doing can make your code much easier for others to follow.

These especially apply for touchy-feely jobs like "information architecture," but can be applied to any job within McCorporation.

1. Clearly define yearly goals. Make sure they're realistic and qualitative, not quantitative. Include in your goals learning something you are interested in. Have your manager sign off on them.

2. Touch every project you know of that's related to your work. No need to get heavily involved. Look at the project, know what's going on, know the technology, know how it will affect your work. Write an opinion, recommendation, or just a report. Make it short and high-content. A pretty picture never hurts. Make sure to email it to PHB, as he probably won't remember to look at your intranet site. At least then his sec2 will have read it. Do this at least once mid-way through each quarter.

3. Write quarterly reports. Trump up any work you've done on popular projects, keep work on politically sensitive projects to a few lines. Again, email to PHB. This time he'll read it. They always read quarterly reports.

4. Request at least two weeks of training a year. Make these requests at least two months before you want to go, or within ten minutes of hearing your boss mention extra budget money. Include summaries of what you learned at these training sessions in your quarterly reports.

5. Request to go to at least two conferences per year. Again, write about what you learned at these conferences. Include in reports.

6. Write a yearly report and hand it over in November, along with next year's goals. Make sure your yearly report shows that you met or exceeded each of your goals.

7. Don't piss too many people off.

-----------------

So that's it. Do this and you'll be an information architect for as long as it amuses you. I'm serious.

Now if you need some ideas on training and seminars, and the general work part of being an information architect, just go here: Object Management Group - you should be able to take care of the rest here.

Good luck.

.NET solves this by making all languages share a virtual machine that defines a bunch of basic data types, and a base 'object'. This means that any object created in one .NET language can be accessed by another .NET language.

You make a valid point about standardization, but then go on to assume that standards can only emerge through a "globally acknowledged standards body".

The fact is that industry consortia pop up all over the place to develop standards outside of ISO and ANSI - in fact, you often cannot go straight to ISO/ANSI, you have to standardize at a "lower" level, then submit your stuff to them to get their "standardized" brand applied.

And often, people ignore them altogether - look at OMG, they have done some wonderful work with CORBA and UML, with literally hundreds of companies providing input into the process.

I really don't see this as a "sun-controlled" effort. Certain members (ASF et. al.) would likely have not gotten involved if that was how Sun envisioned this thing.

- jonathan.

I have seen a couple of Java based Unified Modeling Language tools but no Python support or implementation. It would seem natural to develop in python based on UML, so this must be a large gap in the python suite. What do you think of designing with UML and implementing in python?

Thorn is an opensource UML editor written in Java with JPython scripting but no python code generation.

ArgoUML is an opensource UML editor written in Java with no current python code generation

There's not much philosophical difference between Eidola and the Action Semantics addition to UML due to be finalized next month.

My guess is sooner or later we'll get binary XML encoding, then some "preparsed SOAP", and then finally something similar to CORBA - or M$ would switch to CORBA, which is unlikely because it means, gods forbid, Java compatibility

Opinions are mine only and could change without notice.

Linux isn't a good programming platform for me right now because it doesn't have a standard object model

No standard? What about CORBA? More of a standard than Microsoft's DCOM, even if the API is horrendous.

If you mean no standard across desktop environments, then you'd be right. But object models are far more than ways of making GUI applications interact, so XParts is just the last piece in the jigsaw.

Chris

Spend some time away from AOL for a change :-) OMG (Object Management Group) is the standards body that develops CORBA.