Debu Panda of Oracle has written about Service-Oriented Architecture from a Java Developer Perspective. He delves into what SOA means, why we should care, and the various layers of SOA (Service, Business Process layer, and the Presentation layer).

Best Practices

Here are a few best practices to follow when building service-oriented applications:

1. Do not jump into implementation technologies just because of the hype. Carefully consider whether web services make sense for your organization. Building a service-oriented application using traditional technologies such as RMI may be more appropriate for your use cases than using web services.

2. Modularity of services is very important. Do not build fine-grained services, as this will result in a tightly coupled, brittle infrastructure.

3. For most applications, interoperability is important. Adhere to the WS-I best practices--and even then, make sure to test for interoperability with your preferred clients.

4. If it doesn't make sense to use web services for your application, there are alternatives. Many BPEL process managers, such as Oracle BPEL Process Manager, let you use native protocols.

Read more: An Introduction to Service-Oriented Architecture from a Java Developer Perspective

In related news, both IBM and BEA have announced consulting pratices around SOA, and BEA did a survey to 1000 European Java developers in which 75% said they expect to, or are already building service oriented architectures.

Oracle's BPEL toolset is a very powerful enabling technology. I'd be interested in hearing about real world applications. Has anyone out there implemented business processes with Oracle's process tools?

Our product has been available for download for 2+ years now and we have several large reference customers in production now. Our premier reference customer right now is Belgacom, who is running 20,000 DSL provisions per day through the Oracle BPEL PM and have had BPEL processes in production for 6-9m months. They have built and put in production 300 different BPEL processes, some of which are *very* complex (hundreds of parallel branches, for example).

Other reference customers include:
    Avue (Gov't services)
    Carlson (Travel services)
    Centerstone (ISV)
    Examen (ISV)
    Interaccess (Gov't services)
    Policy Studies (Gov't services)
    Raytheon/NASA (Geospatial data)
    ResortQuest (Travel services)
    European Space Agency (Satellite imaging services)

Dave
_____________________
David Shaffer
Dir Product Mgmt, Oracle BPEL Process Mgr
david dot shaffer at oracle dot com
W: 650.506.1729
http://otn.oracle.com/bpel

Enterprise Service Bus (ESB) is now the model for SOA, not the classic model back in 2001.

The ESB is still up for debate. See http://www.looselycoupled.com/blog/lc00aa00073.html

First diagram has striking similarity to good old CORBA registry service.

The point: Reinventing the Wheel? CORBA vs. Web Services
http://www2002.org/CDROM/alternate/395/
<table border="1" cellpadding="1" cellspacing="0">
<tbody><tr>
<td align="center" nowrap="nowrap">Aspect</td>
<td align="center" nowrap="nowrap">CORBA</td>
<td align="center" nowrap="nowrap">Web services</td>

</tr>

<tr>
<td align="left" nowrap="nowrap">Data model</td>
<td align="left" nowrap="nowrap">Object model</td>
<td align="left" nowrap="nowrap">SOAP message exchange model</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">Client-Server coupling</td>
<td align="left" nowrap="nowrap">Tight</td>
<td align="left" nowrap="nowrap">Loose</td>

</tr>

<tr>
<td align="left" nowrap="nowrap">Location transparency</td>
<td align="left" nowrap="nowrap">Object references</td>
<td align="left" nowrap="nowrap">URL</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">Type system</td>
<td align="left" nowrap="nowrap">IDL</td>
<td align="left" nowrap="nowrap">XML schemas</td>

</tr>

<tr>
<td align="left" nowrap="nowrap">&nbsp;</td>
<td align="left" nowrap="nowrap">static + runtime checks</td>
<td align="left" nowrap="nowrap">runtime checks only</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">Error handling</td>
<td align="left" nowrap="nowrap">IDL exception</td>
<td align="left" nowrap="nowrap">SOAP fault messages</td>

</tr>

<tr>
<td align="left" nowrap="nowrap">Serialization</td>
<td align="left" nowrap="nowrap">built into the ORB</td>
<td align="left" nowrap="nowrap">can be chosen by the user</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">Parameter passing</td>
<td align="left" nowrap="nowrap">by reference</td>
<td align="left" nowrap="nowrap">by value (no notion of
objects)</td>

</tr>

<tr>
<td align="left" nowrap="nowrap">&nbsp;</td>
<td align="left" nowrap="nowrap">by value (<em>valuetype</em>)</td>
<td align="left" nowrap="nowrap">&nbsp;</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">Transfer syntax</td>
<td align="left" nowrap="nowrap">CDR used on the wire</td>
<td align="left" nowrap="nowrap">XML used on the wire</td>

</tr>

<tr>
<td align="left" nowrap="nowrap">&nbsp;</td>
<td align="left" nowrap="nowrap">binary format</td>
<td align="left" nowrap="nowrap">Unicode</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">State</td>
<td align="left" nowrap="nowrap">stateful</td>
<td align="left" nowrap="nowrap">stateless</td>

</tr>

<tr>
<td align="left" nowrap="nowrap">Request semantics</td>
<td align="left" nowrap="nowrap">at-most-once</td>
<td align="left" nowrap="nowrap">defined by SOAP</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">Runtime composition</td>
<td align="left" nowrap="nowrap">DII</td>
<td align="left" nowrap="nowrap">UDDI/WSDL</td>

</tr>

<tr>
<td align="left" nowrap="nowrap">Registry</td>
<td align="left" nowrap="nowrap">Interface Repository</td>
<td align="left" nowrap="nowrap">UDDI/WSDL</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">&nbsp;</td>
<td align="left" nowrap="nowrap">Implementation repository</td>
<td align="left" nowrap="nowrap">&nbsp;</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">Service discovery</td>
<td align="left" nowrap="nowrap">CORBA naming/trading service</td>
<td align="left" nowrap="nowrap">UDDI</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">&nbsp;</td>
<td align="left" nowrap="nowrap">RMI registry</td>
<td align="left" nowrap="nowrap">&nbsp;</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">Language support</td>
<td align="left" nowrap="nowrap">any language with an IDL
binding</td>
<td align="left" nowrap="nowrap">any language</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">Security</td>
<td align="left" nowrap="nowrap">CORBA security service</td>
<td align="left" nowrap="nowrap">HTTP/SSL, XML signature</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">Firewall Traversal</td>
<td align="left" nowrap="nowrap">work in progress</td>
<td align="left" nowrap="nowrap">uses HTTP port 80</td>
</tr>

<tr>
<td align="left" nowrap="nowrap">Events</td>
<td align="left" nowrap="nowrap">CORBA event service</td>
<td align="left" nowrap="nowrap">N/A</td>

</tr>
</tbody></table>

Please, lets open that IIOP port and stop XML abuse and SOAP nonsense.

I thought TSS accepts table, did not read right column carefully. Could TSS accept valid(balanced) tables?

Anyway, please visit the link and see CORBA vs WS comparison table.

I'm am not going to stick my neck out and say that SOA is it but it is a safe bet that CORBA is dead (or at least it is just still twitching...).

Now that's a deep, well-researched oppinion. We should get more of these. Then we could rename this to theslashdotside.com.

Firstly, opening ports is not an option in many companies now especially government. However there are IIOP tunneling alternatives also.

Secondly, IMHO the ESN (Enterprise Services Network (where some want to use ESB)), should support many transports. If your service is talking IIOP the registry or bus should be able to provide async & sync invocations in the same fashion as with web services.

One of the big advantages of web services is that Microsoft is on board. I have spent hours on end dealing with messy COM/CORBA bridging code and integration is infinitely easier with web services (assuming the WS-* completes and transactions/security/etc. are solidified).

Originally web services were not invented as a competitor to LAN-based technologies such as J2EE and CORBA. HP was thinking along the lines of the "internet operating system" and the original web services platforms were targeted towards the "internet model" where *all* invocations were occuring externally. I think the competition at that time was very indirect however now the model is primarily intranet/extranet so people are arguing one side or the other. SOA however, should really support all at least in theory.

Firstly, opening ports is not an option in many companies now especially government.

People are way to often settle for such answers.( Why? - Because it is. – Hmm, OK)
I slill asking: Why?
I have not heard any sound technical argument that would explain why zoo of protocols and wrapped ones rushing through one port is better(or more secure) than orderly passing of predefined things through dedicated ports. Any links?

This is usually one of the first questions that pop in my mind but usually are left unanswered by these articles. They all assume stateless services.

So if I have the check-if-an-article-is-in-stock and remove-article-from-stock stateless services and I'm building this webapp, do I implement the session in the webapp or should there be a session service.

Personally I feel that the concept of having an explicit session to consider, is something that is a by-product of the fact that one is building a webapp. A regular application has an implicit session (it is running) so why introduce the trouble there? Hence I would be in favor of placing the session at the webserver, not in an EJB or whatever; that is where and why it exists in the first place.

My company is working on 1 project with BPEL. But I can assure you that its not all that great a tool. Simple things are easy, but when working with more complex structures it gets more difficult.

Simple things are easy, but when working with more complex structures it gets more difficult.

It would be great if you will provide further description of the simple vs complex structures you mention. What is "simple" and where does the complexity arise? Do you think the issues you face are a reflection of BPEL? Does BPEL lack the features you need to tackle your complex problem?

Well, I have been thinking this since 2001, when everybody thought Web Services would replace everything in a few months. It is now much more evident, as exposed in the article, that WSDL/SOAP and RMI (or RMI/IIOP) should co-exist in a well designed SOA.

But there is still a critical question: how do you open that port? CORBA has a lot of trouble working through firewalls. I have been working on the issue for years (for the Italian Government, which must use firewalls within its network for undiscussed privacy issues), and we had trouble with cross-firewall interoperability even with two versions of the same vendor's ORB!

So assuming that the overall architecture is a SOA (stateless objects/endpoints) even if you use RMI as transport, is there a standard, well-documented way to achieve RMI or RMI/IIOP interoperability through firewalls? The future of two government projects I am currently working with depends on this issue, so any suggestion is welcome.

So assuming that the overall architecture is a SOA (stateless objects/endpoints) even if you use RMI as transport, is there a standard, well-documented way to achieve RMI or RMI/IIOP interoperability through firewalls? The future of two government projects I am currently working with depends on this issue, so any suggestion is welcome.

Jini allows this - with it's Extensible Remote Invocation, you can specify an exporter (that can export multiple objects) and specify the port you want to use - and you can use SSL and Kerberos.
 

--Calum

Why not have a web service facade for applications needing access from outside the firewall and native service end points (like stateless beans, RMI ) for applications accessing from within the LAN? The web service facade would be a separate deployment which natively interacts with the actual service and would not modify the actual service deployment.

Saju Thomas
www.ishisystems.com

A stateless bean invocation is transactional and secure, especially if you use RMI/IIOP which relies on JTS/OTS for Transacionality and CSI for security. A WS invocation is usually secured using non-standard methods, although the SAML specification is perhaps going in the right direction to solve this issue, and it is even weaker WRT transactionality. Pls note that when I say secure I mean authenticated and authorized, not just SSL-encrypted.

So if the outside-the-firewall application has to use the inside-the-firewall service in a secured transaction, I stil have the feeling that a web service, whether using SOAP or not, although solving the firewall problem, is still lacking, in performance and services provided, if compared with what RMI/IIOP or RMI/EJB can achieve.

But there is still a critical question: how do you open that port?

Very simple. Exactly the same way as port 80 is open. And the same way as port 23, 22 and others.
I mean that we should act in a way that stops FUD : ask a full explanation of reasons why this and that is considered harmful for this particular configuration. And do not accept hot air as answer.

I hate to say this, but I've worked at a few places where the admin couldn't configure a firewall. They had to call up cisco and pay big bucks to have the cisco consultant come open up a port. At one place, the head network guy absolutely refused to do it. When we offered to make the change ourselves, test it and verify it was configured correctly, the guy still screamed "no, you'll have to find some other way." Ultimately, this meant we co-located our servers at a big ISP and the sys admin for our group handled the firewall. The downside is when we need to do work on the machines like add more hard drives, the sys admin had to drive 15 minutes to the ISP.

Some are dumb, some are lazy, and all of them (and many vendors) are interested in ballooning of self-importance by all means possible.

Their position is exploited (they used as boogey-man) by software vendors to promote meaningless ‘solution’ for ‘non-existent’ problem, everybody is busy, number of employed increases, economy is growing.
I guess I should shut up and roll my sleeves implementing Cameron’s idea of XML based image format for true cross-platform compatibility.

I think you've got a good point and it sounds like you are preaching to the choir here. In government installations I have worked where classified material exists I would probably replace "lazy or dumb" with "paranoid". Possibly this attitude propagates down into the rest of corporate America since people who have been security officers in government related work seem to yield the highest demand in standard corporations as well. This is a cool link where a proven security expert, Bruce Schneier discusses the issue with respect to DCOM.

http://www.schneier.com/crypto-gram-0006.html

...it sounds like you are preaching to the choir here.

There are plenty of readers and I am positive that not all of them are joined the chorus :)

...it sounds like you are preaching to the choir here.

There are plenty of readers and I am positive that not all of them are joined the chorus :)

WS can use object oriented protocol and XML, so it is cool and easy-of-use by definition. CORBA stuff is very complex because you need to configure evil firewall (probably on some very complex legacy UNIX box). IDL is evil too, it is not markup. So I do not think somebody can agree with you on this forum :)

It's probably just me, but configuring cisco or software firewall isn't necessarily easy, but for a trained sys admin or network admin, it should be straight forward.

If you're talking about something like checkpoint, an experience sys admin should be able to handle it. If you're talking about logging into a cisco router and configuring it, than it's a bit harder. Even a developer with minimal experience with firewalls should be able to figure out checkpoint in a few hours. Of course, the catch is "should". having said that, it is easy to screw up the firewall rules, but the users will usually scream at the top of their lungs when that happens.

WS can use object oriented protocol and XML, so it is cool and easy-of-use by definition. CORBA stuff is very complex because you need to configure evil firewall (probably on some very complex legacy UNIX box). IDL is evil too, it is not markup. So I do not think somebody can agree with you on this forum :)

One of the first things mentioned about soap is that you dont have to worry about firewalls. I find this very strange because both corba and soap are ways to perform method invocation. If an organization doesnt allow a corba service to be exposed without proper monitoring, why should it allow a soap service to be exposed?
-ss
www.indianblogs.net

I have plenty of admin friends who are paranoid about security and require people to use ssh or vpn to port forward. In cases where we really need to open up a port, the reasonable approach is to explicity block all ports and IP's that are not allowed as the first level of security. After that, usually SSL with third party certs provides a reasonable level of security. At a previous job, we setup the production such that to update the production cluster, you had to ssh in and from there tunnel out to staging to get the release. It was a bit of a pain when you're in a rush, but I much rather be safe than sorry. We went as far as to get the sys admin to run a port scan and try to attack the cluster to make sure casual hackers couldn't break in.

I don't really understand the notion of doing everything over http and port 80 because the admin isn't willing to do his job and configure the network appropriately. Back to the topic of SOA and webservices, has anyone done a survey to see what percentage do pure HTTP or use some other transport protocol?

I don't really understand the notion of doing everything over http and port 80 because the admin isn't willing to do his job and configure the network appropriately.

As stated in Schneider's article linked above, you need a whole range of ports to fully use DCOM, CORBA or RMI through a firewall. I do not believe this may be acceptable to a sensible sysadmin, since some of the ports would be open without a corresponding daemon running on the server side => wide room for trojans / backdoors. I have worked with products that proxify each and every IIOP call through a well-known port other than port 80, but this is a vendor-specific solution that a government customer would be unwilling to accept, preferring an apparently safer SOAP/HTTP solution. I stress apparently.

Back to the topic of SOA and webservices, has anyone done a survey to see what percentage do pure HTTP or use some other transport protocol?

Dunno, but with all the hype about "WebServices=simple" I'd bet most implementations use straight http, with the most advanced feature being https.

As stated in Schneider's article linked above, you need a whole range of ports to fully use DCOM, CORBA or RMI through a firewall.

Sun's JRE automatically tunnels RMI through port 80. Of course for SOAP and RMI this isn't bidirectional tunneling. But JXTA simulates bidirectionality over port 80.

As stated in Schneider's article linked above, you need a whole range of ports to fully use DCOM, CORBA or RMI through a firewall.

Sun's JRE automatically tunnels RMI through port 80. Of course for SOAP and RMI this isn't bidirectional tunneling. But JXTA simulates bidirectionality over port 80.

Is not that too high price to pay for admins stupidity and paranoya?
Lots of troubles without improving sequrity bit, even making things less secure because all kind of stuff creeping through port 80.

Lots of troubles without improving sequrity bit, even making things less secure because all kind of stuff creeping through port 80.

I've used the web edition of TurboTax for years. It's a fundamental misunderstanding to consider HTTP somehow less safe than punching arbitrary holes in the firewall for arbitrary binary protocols that support arbitrary applications. HTTP centralizes a server's security in one web container, which is ideal.

I've never heard of an intrusion on the Grid (Globus), which combines passwords with mutually authenticated HTTPS certificates. With its supercomputers and silos, the Grid should be a honeypot for crackers. SOAP makes it easier for administrators to do content-based traffic security. The ApacheAxis-based Grid has better resource management infrastructure than any other J2EE or CORBA deployment I've seen.

it destroys the ability to leverage SOA infrasture tools (SOAP intermediaries)...one of the best things about SOA is you get to do stuff in infrastructure that you used to do in development

Try to federate with external partners using MQ-Series!!!!

Sun's Javapedia has links to various SOA articles:

http://wiki.java.net/bin/view/Javapedia/ServiceOrientedArchitecture

There's an interesting article on webservices.org that shows how a) vendors are positioning themselves for SOA and b) how complex the broad area of SOA is for anyone to really follow anything but a few of the key trends and vendors:

http://www.webservices.org/index.php/ws/content/view/full/53035


PJ Murray
CodeFutures
http://www.codefutures.com

Here are some thoughts on SOA from a Java Developers perspective: it's RPC rebranded for no discernable benefit other than to sell consultancy services to idiots.

Worse is the emphasis on SOAP. Sure, SOAP is great for B2B because it's reasonably programming language independent and people get a warmer, fuzzier feeling watching XML go past instead of IIOP. Despite that SOAP is a third of the speed and designed by a bunch of committees that haven't met a header they didn't like and have a pathological desire not to learn from any previous technologies that have solved the same problem for more elegantly.

Even worse than that is the implicit emphasis on point to point protocols. The advantages of using an enterprise message bus instead of http/rmi/etc. are huge.

The sad part is that RPC is a reasonably good idea or it wouldn't have been around for so long. So, in the event that anyone is stupid enough to pay for SOA consultancy, here are some other really great new idea's that I'll happily sell overpriced advice on:

Relational Oriented Data Storage: That right, save your data in rows, columns and tables, use our Declarative Query Language to View, Change, Remove and Add!

buy now and you'll also receive some of these innovative products:

Object Based Programming!
Asynchronous Note Passing!
Text With Links Protocol!
Code Storage with Recoverable History!

*sigh*

Worse is the emphasis on SOAP. Sure, SOAP is great for B2B because it's reasonably programming language independent and people get a warmer, fuzzier feeling watching XML go past instead of IIOP. Despite that SOAP is a third of the speed and designed by a bunch of committees that haven't met a header they didn't like and have a pathological desire not to learn from any previous technologies that have solved the same problem for more elegantly.

Actually SOA doesn't require use the SOAP. SOAP can be one of the choices you have. Since SOA is tied into Web Services by default it gives the perception that you have to use SOAP.

Apache WSIF provides an elegant way of accessing existing components or apps without having to use SOAP, but at the same time providing loosely couple model.

raghu

I'm not sure why people mis-interpret the concept of SOA with a mechanism of allowing people to use your SOA. If you want to model yourself with an SOA, then do so. The choice about what interface/transport to stick on top is neither here nor there. If I have several services that need to communicate to each other on the back end, why ever would I use a web-service, or SOAP or anything like that?

That's what RMI is for. If you also want to expose the interface to some third parties, then a web service interface can be added as well.

That's what RMI is for. If you also want to expose the interface to some third parties, then a web service interface can be added as well.

You can do all of this and have secure communications in your services using Jini, plus if you already have a Web service, you can add serialized proxies to that service into a Jini LUS and still communicate with it through SOAP, yet use this through a proper Java interface - the way that you communicate is an implementation detail.

--Calum

Exactly. This is what describe in this article

"Most developers often think web services and SOA are synonymous. Many also think it's not possible to build service-oriented applications without using web services. To clarify, SOA is a design principle, whereas web services is an implementation technology."

regards
Debu