Borland's SOA Push: JBuilder 2005 and Beyond


News: Borland's SOA Push: JBuilder 2005 and Beyond

  1. Borland's SOA Push: JBuilder 2005 and Beyond (4 messages)

    Borland's chief scientist for developer tools Rick Nadler, has been interviewed on the future of SOA for Borland. The interview covers how J2EE developers can use Web Services Design, insight on WSD features for SOA debugging, refactoring, and a glimpse at Borland's future SOA tools roadmap, including support for SOA patterns.

    What other features will Borland be working on to make SOA/web services development and deployment easier for Java/J2EE architects and developers?
    In the future you might expect [several improvements]:

    1. We're looking at doing more work on web service/SOA audit tools. Today, in JBuilder 2005, while we have audits that check for various accounting styles, and added plug-ins to check for security styles, we don't have any automatic audits for dealing with how to tell a developer to build more coarse-grained [code].

    So, internally, we're thinking we might want to add audits, or guidance, that would scan code to tell the developer, "You can service this as a web service if you want, but be aware that you have 17 parameters in your method call. So, web servicing this may not be the wisest way of doing it."

    2. We're also thinking more about improving message-oriented debugging. We're moving toward an "extensible debugger view " for developers. And that's because once you move to SOA you're not necessarily going to want to set break points at lines of Java code, you're going to want to set break points at this message arriving with these characteristics; and

    3. We are working closely with other vendors and The Middleware Company in developing SOA Blueprints.
    Read the interview: Borland's SOA Push: JBuilder 2005 and Beyond

    Threaded Messages (4)

  2. Are SOA's irrelevant?[ Go to top ]

    Since a whole day went by with no comment to this news flash from Borland's chief scientist for developer tools, I guess I can ask the question. Are SOA's gaining traction anywhere? I mean besides Google and Amazon.

    Is it wise for Borland to be focusing so much time and energy into a protocol that appears to be so bloated and counter to performance? They spent many years feeding us CORBA, then they blessed RMI, and now SOA. Sure, there are needs for remoting, but most software architects have always been doing everything in their power to limit remoting.
  3. SOA is broader than that[ Go to top ]

    If SOA was just remoting, I'd agree with you.

    But it isn't. SOA is not just an architecture, or another way of distributing applications, its a complete mindset change. In the future it will affect how business requirements are captured, how applications are designed, the methodology behind implementation, and the infrastructure for deployment.

    The current incarnations may seem to focus on Web Services, but the long term goal of a distributed services grid will expand this to ensure that services are invoked in the most appropriate manner for any given client/consumer pair.

    We're not there yet, but increased vendor awareness of this vision does serve to get us there faster.
  4. SOA is broader than that[ Go to top ]

    SOA is not just an architecture, or another way of distributing applications, its a complete mindset change.
    I don't mean to sound too sarcastic, but I wish I had a dime for every one of these paradigm shifts that the industry predicts.

    If it isn't remoting, then is it is remoting+interoperability? BTW, I would consider a Java object invoking a .NET object to be a form of remoting since intraVM serialization would take place. So is SOA suggesting that I invoke my Java objects that reside in the same VM using some sort of new protocol rather than a VMT?

    Ultimately, SOA is defined with such broad strokes that any interface between two components is now an SOA. At what point did good solid design principles, suddenly become "a complete mindset change"? Design by interface has been a good idea for many years now.

    The industry momentum on the other hand is huge. That always causes me to pause. Borland is in good company pursuing SOA along with Sun, IBM, Oracle, BEA, Nokia, and many others. Companies like The Middleware Company are also ramping up their involvement.

    It all seems pretty evangelical at this point. Where are the use cases that actually make sense? I mean, besides remoting (which is reinvented with a new protocol every 6-8 years) when would you use SOA?

    SOA offers interoperability where bridges existed before. I can foresee that SOA may eventually only provide a standard means for talking to a bridge in the end with additional performance penalties, more points of failure, etc.
  5. SOA is broader than that[ Go to top ]

    I completely agree with you... Since CORBA was the main "interoperabl" remoting protocol, not much has changed in how enterprise applications are designed. Okay, J2EE, Hibernate etc. and the ease-of-use of RMI semantics have made things easier, but not really "different". We designed services since RMI emerged (or did anyone in any running app expose each entity as remote object?), Session beans just partially forced you to write services, so what is so great-and-new about SOA? It just means designing for reusability, so one application is built on top of another, communicating mainly via messaging... ask IBM since when their MQSeries (now WebsphereMQ I think) was used by customers to do exactly this!
    Especially SOAP and other XML/http remoting protocols are the worst thing invented (and gaining traction) in a long time... the main argument for SOAP, http transport, can be used by other remoting protocols too. The argument of easy firewall-transition is, at best, a nice wish. Instead of opening an RMI/CORBA port for _efficient_ remoting, we now make opening port 80 for http a security risk, because the "risk" is that malicious remote-packets can be used to attack servers... now they can be sent to port 80... what a pity...
    While I see use for SOAP/XML remoting in some cases, they mainly transfer the "security problem" and sacrifices a lot of performance for this.