Anyone out there has been following up on the the next tech leap ahead of "Web Services" and how they are facilitated through some XMLish transport mechanism, must be thinking, well what about all these years that we have been forging ahead from half decent middle tier object transport protocols to some thing mature as EJB container implementration, where does SOAP/XML/XAML, etc. leaves EJB?
Do you really need EJB in two years time if XML by then will provide you with almost all the functionality of a mature container, remeber how EJB edged IIOP out, although it started from behind in the race, are we witnessing this all over agin with XML marshalling of Objects. Where will it all stop, anyone with thoughts on this, and how to startegically position company architecture to reap in the benefits of "Werb Service", please write back I'd like to hear your thoughts on this.
Emad J. Benjamin.
1) EJB has not edged IIOP or CORBA out. Actually the newest version of EJB are very very CORBA like and include the use of IIOP
2) XML a file format not a framework for distributed computing. Its is also IMHO a very heavily overused format. The biggest benefit to XML is that it is self describing so it is easy to use as a data exchange format for things like EDI where neither side uses identical data formats. How many applications really need this?
3) I think there is alot of room for the growth of design pattenrs in how we effectively marshall information over networks.
Internet Applications Division
I agree with point one but that is because Sun had decided, roughly about two years ago to support IDL, in waking up to what Visigenic had already been doing through their Caffeine product. Had they not done that, it would have been a completely different story here, I know sun is so focused on J2ee that they are missing the larger picture focus for XML, although they have included XML as a component in the stack, they havent embraced it like the other big guns. So, what will Sun do to reap in the next leap ahead of "Web Service" architecture, the big guns are talking about XML Beans for persiteance, XML/XSL for presentation, XAML/SOAP for transportation, that sounds like a lot of duties for what seems to be a simple/sophisticated markup language.
Sun will do something about this in a big way more than what they have so far, and they will do it through their EJB architecure, just like it introduced JMS EJBs to reap into the publish/subscribe architecture markets. So what will it be, when, and how?
I agree with Dave on this one. XML/SOAP/etc is not a replacement for EJB. I think there will be more integration between the two as time goes on. XML is a way for different systems to share data, meaning you could have an EJB sever talking to a BizTalk server, talking to a CORBA based server, etc. SOAP is one really slick way of having these systems' objects talk to each other and send data without having to know what the other side is developed as.
XML is a good way to marshall objects between these systems, since they can all read XML. As long as the format of the XML (via Schemas perhaps) is agreed upon between the systems, you have object system talking to another one and knowing none of the details of each other's implementation.
I think the original posters point is this:
1. EJB is used for portability reasons. There is an accepted performance cost to this, which is evident by the lack of TPC entries for EJB-based architectures. Native application servers (e.g. CORBA, COM+...) provide a much more performance orientated system.
2. SOAP and web services (incl UDDI) provide an open way of providing interfaces to all systems. Given the non-EJB versions of the same application servers provide higher performance levels, then will a "native-app-server + SOAP" pattern sideline the reason for EJB existing?
Personally, I think the web service pattern makes a lot of sense and performance cannot be ignored within a server-centric architecture.
In response to Lee Fuller's comment on performance.
I think you have touched on exactly what I was saying in my original message with your second point, about if "XMLish/SOAP base web service architecture" will EJB be just as valid? But of course we know that the current XML based system performance is very sluggish, and this where technilgies like fast XSLT/XPath, or intelligent XML Parsers will have to forge ahead and imporve on XML's current state of runtime performance. If peformance improves in XML, and Sun doesnt do anyhting to reap this "Web Services" leap ahead, then yes EJB will be edged out. But as I said earlier Sun will act to save its day.
Sorry I disagree. I dont see how XML a data transport format, can edge out EJB, a distributed computing model. They are even in competition. If anything, XML file formats may be used as heterogenous data format for data exchange across systems, but it will never fill the shoes of a distributed computing model. What about tx management, business rules implementatin, etc. Its like saying that cars will replace oranges. They arent even in competitiion, although you can fill a car with oranges.
Internet Applications Division
I agree. The two technologies will complement each other.
SOAP and XML will connect the enterprises across internet,
whereas ejb will be used for building distributed apps running inside the enterprise. SOAP and XML will connect the islands of ejb apps to provide the the so called
I think you have not got the point that Benjamin is trying to drive at . You are just taking one side of the argument .
He says that XML/SOAP with some other model (say COM) can replace EJB in the near future ,
I feel that there are possibilities for that .
COM + XML/SOAP > = EJB
is the question and I feel that this equation is possible
But , SUN will definitely wake up to this , towards that
The point of Emad's original message is really that XML/SOAP like languages (protocols?) actually substitute RMI and hence kill EJB as the model for distributed applications. You can easily use regular JavaBeans to build an application, and if you need to call a method from another bean, just send a SOAP message and work out the response.
As Sridhar rightly pointed, with his formula is that EJB is no longer *the* choice for distributed computing, but *a* choice. You might use COM, DCOM, EJB, or JB and rely the distibution part of the application on SOAP.
But what your missing is that RMI is not EJB. Its the container that makes EJB not the protocol. Whos gonna grab that SOAP message, instantiate the bean, handle its lifecycle, cache connections, handle security, manage the transaction, etc. So when you just apss this SOAP message to some simple JavaBean, whos gonna make this all work? You wanna write all that?
EJB is a framework, SOAP is a protocol. A protocol does not compete with a framework.
Internet Applications Division
Dave is right,
EJB is an infrastructure for developing server side components. EJB 2.0 containers will be able to support both synchronous and asynchronous protocols to access these components. We've seen several protocols bridges to these components so far: RMI, T3 from WebLogic, RMI/IIOP and now JMS (Message Beans). You can expect to see SOAP being added to this list by vendor implementors. I don't see why Sun need to be involved at all.
The container provides several advantages to its developers, transaction management, security, resource management (pooling, throttling) and (very importantly) it provides a standard that tooling developers (read IDEs) can use so that we get nice tools to write and develop the applications.
It also provides an interface to the underlying infrastructure that should allow other middleware products such as message brokers, workflow systems to be built on top. This one advantage is a very important one for me and is probably how vendors will charge premium prices as EJB servers become more 'vanilla'.
SOAP is basically the equivalent of GIOP in the Corba world. HTTP/SOAP is comparable to IIOP or RMI over IIOP. SOAP and GIOP specify how to marshall a method invocation/service request into a binary representation. GIOP has mainly performance advantages over SOAP here. SOAP is more flexible in terms of interface brittleness. Remember, you could transport GIOP over HTTP if you wanted. HTTP/SOAP and IIOP just specify how SOAP or GIOP is transmitted over a specific transport.
IIOP has extensions like OTS that also allow distributed transactions. This aspect doesn't seem to be address by SOAP currently.
HTTP/SOAP should really be compared solely against RMI/IIOP or just IIOP.
But anyway, I hope the point is clear. You still need a component model and a runtime environment that allows runtime loads to be managed/throttled and allows a tooling market to develop supporting it and this is what an EJB container (or for that matter, COM+) runtime gives you today.
Great clarification Billy. I agree irt SOAP vs IIOP as a more fair discussion point. BTW, as an aside, in Sybase EAServer we do indeed support not only straigh IIOP but also marshalling IIOP right over HTTP as you mention. Well, you might say tunneled within HTTP but thats all from your point of view :)
Internet Applications Division
I think the other thing we also need to consider is that the reason why SOAP is being used is because it runs on HTTP. We should consider that in the not too distant future there will be/are other protocols more suited to Broadband use other than HTTP and that firewalls will allow "trusted" non HTTP protocols to go through them such as those used in conjunction with EJBs. Where will that leave SOAP when other programming paradigms can, do and will use other protocols.
Absolutely, thats the point. SOAP is merely a transport. You still need a runtime infrastructure to process the requests arriving and J2EE and .net are currently your two alternatives for implementing this infrastructure. Does anyone know if any company has implemented the OMG Corba component model yet?
As far as I have understood the OMG component model is not yet complete. We would consider implementing it upon its completion. Do do intend to fully support EJB 2.0 and J2EE 1.3 interoperability however.
Internet Applications Division
HTTP tunnelling of EJB calls is up to the App Server vendor. Weblogic 6 does allow HTTP tunnelling (IIRC). By the way, EJBs can be RMI or CORBA based, it's up to the vendor. Also, RMI does currently support IIOP...so really the only oddball is COM as far as Server Side Components go.
WHAT'S IT ALL ABOUT ?????
There seems to be a bit of confusion as to what XML, SOAP, RMI, IIOP, EJB and DCOM are all about (although some people have pointed out the facts)
(Apart from that, I have a few SERIOUS QUESTIONS on the validity of SOAP's fanfared "benefits" .... if you want to go straight to that, scroll towards the bottom of the message...)
Firstly, COM, RMI and CORBA are distributed object models. They neither define a PROTOCOL or DATA FORMAT nor do they define an application framework.
It just so happens that CORBA is done over IIOP and Java RMI can be done over JRMP and IIOP. Equally, either of these could be implemented over SOAP. (look around the omg site for SCOAP).
EJB (which incidentally is a subset of CORBA3's Component Model) as well as Microsoft MTS is an application framework. While this framework *may* not be as performant as raw Java/C++ applications, they are very quick to develop business applications on because the services (distribution, lifecycle, persistance .... etc) is all done for you. The theory is that you just write busines logic.
Just to clarify the oft confused associations between the above technologies:
RMI-IIOP is part of the framework of EJB is which is used for the distribution of objects (Microsoft use DCOM for MTS).
So, in summary, if SOAP is in competition then it is with DCOM, JRMP and IIOP. Anything else is comparing cars with oranges (as was mention above)
SOAP stands for Simple Object Access Protocol. I know that everyone probably knows that BUT, the first word is the key one that everyone seems to forget when comparing it to the likes of DCOM and IIOP.
Firstly, SOAP is a great lightweight RPC or messaging protocol. It has low overhead and is infinitely flexible.
However, what happens when you want some sort of propagation of security context or transactional context? What happens (as in the case of DCOM and JRMP only) that you want to have some sort of distributed lifecycle management (distributed garbage collection)? Pretty soon, SOAP becomes COAP (complicated OAP). Once you want (and you will want it) start having to marshall and unmarshall similar amounts of *native* data, then SOAP becomes very expensive on the processor (as marshalling is inherantly more expensive to parse/marshall) and on the network (the ascii format can only ever amount to more data down the pipe).
Basically, once your message payload reaches a certain size the "lightweight" nature of SOAP is lost as it is now more expensive on the processor and the network as its "rivals".
What are some of the other "benefits" of SOAP?
1) Platform independant ?
The one big thing going for SOAP is the fact that Microsoft
happen to be embracing it and therefore it *could* be a bridge between the Microsoft world and the J2EE world (as well as the rest of the world!). HOWEVER, beware of microsoft's method of standards adoption. The track record on Java & LDAP is evidant and it is likely that XML/SOAP will go the same way.
2) Language independance?
IIOP is pretty language independant, as is DCOM. SOAP is arguably more so (I realise that) but for how long? (refer to point 1)
3) HTTP, hence no firewall issues ?
One of the nice features of SOAP is that it is over HTTP and therefore it is easily encrypted (SSL) and it passes through the HTTP port on almost every firewall in existance with no extra effort.....
All this is true - but now, in a similar way that JRMP, DCOM and IIOP are frowned upon by IT Security, so too will SOAP. Allowing SOAP, or in fact any RPC or messaging protocol unhindered through a firewall will become a serious security risk and a big hole in the firewall.
Therefore, will security on our favourite HTTP port be clamped down as it is for DCOM and IIOP ?
My firm belief is that JRMP, IIOP and DCOM(well, ok, DCOM is a little nasty) should have an equal status in importance when it comes to firewalls. Designing your entire distributed object model (and hence, your e-business) around a firewall seems a little like the tail wagging the dog to me...
4) No need for proxies ?
All the distributed object models pivot upon the same implementation. There are client-proxies that communicate with server-skeletons (over either IIOP,DCOM or JRMP) in order to hide the distributed nature of the objects from the developer. The developer just calls the methods on the proxy object.
Well, if we use SOAP, where do we gain? We have an XML parser/formatter for the payload (just like IIOP marshalling) and unless we implement the RPC/messaging ourselves, we will have "helper" classes that convert method calls into XML...... er, isnt that a proxy?
Dont get me wrong, I think that SOAP has a place for lightweight messaging and rpc. However, IIOP is a distributed computing protocol that has evolved over some considerable time and encapsulates lots of inputin the form of collective knowledge and experience gained from all quarters of industry. Protocols like IIOP are around for a reason .. and will continue to be so.
All that said, I am no expert on XML. There may be something - some key concept - that I have missed. If so, I would be happy for that to be pointed out to me.
No-one in particular
When I said:
"as marshalling is inherantly more expensive to parse/marshall"
what I *meant* was:
"as **XML** is inherantly more expensive to parse/marshall"
"the ascii format can only ever amount to more data down the pipe"
SOAP payloads can be compressed and ascii compresses VERY nicely. In fact on a recent project this was used and was very successfull in improving the performance of the application.
The compression had no significant impact on the performance.
my 0.02c worth, anyway
What you say is true.
However, compression/decompression adds even more cpu expense to the the already high cost of the XML parsing/formatting.
You say ASCII compresses well. How well does utf-8 compress?
I seem to remember SOAP may also be run over other transports than HTTP. The docs with the IBM implementation on Alphaworks at least talked about for example email transport.
So I think it will be no problem adapting SOAP to new protocols in the future, it can be done.
I do agree with Dave. EJB specification is not about components or protocols, but it's about container - the server side mechanism for handling concurrency, persistency, sessions etc. It's the whole framework. This framework services can be used using any kind of protocol (it may be SOAP for example).
Here is another funny matter regarding performance. Microsoft's .NET platform will run on a virtual machine (a la Java). Microsoft is actually following Sun's(Java's) lead in this case. Java's advantage is the "Write once, run anywhere" motto. Java allows a corporation to choose its own OS, its own hardware. MS does not...currently. MS is promising to port the .NET virtual machine to other OSes. But as it stands, MS is behind the race.
Currently the two competitors for Enterprise applications line up like this
<tr><td>Operating System<td>Pick an OS<td>Windows NT
<tr><td>Programming Language<td>Java<td>Pick a language
<tr><td>App Server<td>Pick one<td>MTS
<tr><td>Database<td>Pick one<td>Pick One (SQL Server preferred)
<tr><td>Web Server<td>Pick one<td>IIS
So as you see, Java's advantage is the number of choices it allows. Of course most companies tie themselves to a particular platform anyway. But at least you're not forced into one.
MS has a big advantage in that it allows any language for programming. But Java has a head start. You choose.
As a final side note: I recently finished a project for a very large company. They were gung ho about soap, java, and EAI. We built a development kit that provides a SOAP interface to legacy apps with minimal programming required.
The company wanted to support using SOAP over multiple protocols (not just HTTP). One of the protocols they wanted to support happened to be RMI. Now if anyone knows about RMI (which I hope is the case for most of you) you will see the irony of it all. We transformed a full-featured RPC protocol, into a transport for another RPC protocol. (The interesting thing to note is that it is very fast and robust even in production.) It gives hope for using SOAP within the J2EE platform. Would someone go ahead and make that SOAP EJB? I'm too lazy to do it myself ;)
Thank you Michael!
I fail to see why people are so set on pitting SOAP/XML against J2EE/EJB/Java. That is, unless there are alterior motives behind some of these responses. For example, how many of these responses are by those who stand to gain from the adaptation of SOAP.
SOAP and XML are simply additional technologies to add to a software developers "bag of tricks" (along with HTTP, Java, EJB, etc.) to help solve software development problems. There will always be more and newer technologies. The only distinction is who is backing them.
If I am a Microsoft/COM developer and EJB/Java offers the best solution then I would be doing my employer a dis-service by not proposing EJB/Java as a solution. Likewise if I am a Java developer and SOAP/COM offers the best solution I would be doing the same dis-service. Then again some combination of SOAP, COM, Java and EJB might offer the best solution. Of course, there are other reasons why particular technolgies are chosen but lets continue to keep this discussion focused on the technolgies themselves.
I agree with you that there is some confusion about where SOAP lies in relation to other technologies. However, I think this has largely been explained away by the end of this thread.
Moreover, I dont see SOAP as a Microsoft/COM issue either (however, they have backed it very heavily to the exclusion of all else).
My main question is why SOAP seems to be such a flavour of the month compared to other established RPC/messaging systems. My primary question (see 4 posts above) revolves around whether XML is suitable for the marshalling format of RPC or messaging.
My argument is that it is fine for *simple* message/rpc calls - however, rarely does anyone have simple requirements. As soon as you have any one of the following: large payloads, requirements for transactional context, authorisation, security then SOAP's trumpetted advantages dissapear. ... and none of these requirements are all that exotic - they are everyday requirements.
The other issue, which I have struggled to find much discussion on are the security implications of letting SOAP flow unhindered through the HTTP port on firewalls. One of SOAP over HTTP's much trumpeted advantages is that it is meant to work seamlessly with almost all firewalls known to man. However, how SOAP is going to be secured (at the firewall) is a big question I havent seen asked a lot - let alone answered.
This thread :
might also be of interest in the -
J2EE vs M$ .NET debate...
I like Dave's comment about cars and oranges.. I hope you mean to say that EJBs are the cars, and XML is the oranges :-)
As for other comments on performance, to a point I can agree, but for most applications, such as messaging, or 'lite' data transfer, the performance hit isn't that big, at least not in what I've seen used. When you get into really large xml structures, sure you take can take a big hit, but you have to have a pretty good size XML document to really notice, especially on todays hardware. I've seen serialization of object graphs that were up to 5 levels deep and several hundred objects in the graph and you would barely notice it, and that was with DOM.
The Middleware Company
WRT Robert McIntosh's comment on Performance.
The way in which XML is being promoted as THE language/format of data exchange, I recently worked (not to mention company names) on a project where XML was used in a market feed situation, for almost realtime data feeds, and the system was taking a big hit due to XML, of course I will not go into the solution that helped the company speed up the XML translation, as it is proprietary to them. But be aware of using XML everywhere. This is not to say that I dont believe in the future of XML, actually I do, we just need to see a little more performance from it, could be 6months to a year from now.
Again peformance enhancements are just a matter of community support, all of the big technolgies went through it, like Java, C++,etc. they all take time to mature, and what XML has going for it is the community support, and this is why I'm betting on it, but with caution in terms of where it is used in current real business applications.
Always enjoy Dave's comments. I was confused about the comparison between XML and EJB. I can see comparing EJB to stuff like CORBA/COM/RMI or at least talking about them in the same context. Guess I am still learning about XML but it seems to me that XML is just a way for people/computer systems in diff. companies to send info. to each other over the internet. Once the info.(XML) has been sent the receiving end would then use servlets/jsp with EJB(s) to handle the data. I know that XML is used in the deployment descriptor. But again the XML is just info. not logic.
Let me explain please the disadvantages of function call oriented network data interchange approach, such is RMI, CORBA and SOAP compared with pure XML message interchange:
1 once you add a new parameter, you have to communicate it and recopile the IDL, the code to manage it (on both sides).
2 no streaming possible. in case of very long messages, the hack is to split the message, to create a protocol to send record by record and so on.
none of these problems are present in a XML document exchange:
1 once you have all the parameters embedded in the XML document , and the handling logic in both sides, the addition of a new parameter element in one side does not break the other side, if both sides uses the XML DOM. It is possible to interface the new service with older client versions. What communication protocol does that?
2 streaming comes naturally in message based interchange methods.
streamed processing is also a very good feature. (for how long have you been using Unix pipes, before the object oriented invasion?)
XML solve all the problems of message passing communications, and keep the advantages. To encapsulate the power of structured document interchange in the strech methaphor of a matematical funcion invocation is a forced way to understand computer communications.
what is seen in both points are applicable to any data interchange and any data definition.
I´m sorry if I am taking a radically different approach, but it is for me necessary to express that the object orientation paradigm, as now is understood, is not the better approach to solve every computation problen .
Alberto Gomez Corona. Ibermatica.
I wonder if my previous messages have been the cause to justify this silence.
May be because I express some ideas far away from the programming context in which you used to be involved.
To concile messages, streaming and object orientation, I can say that in the original object orientation methapor definition, as was defined in the Xerox laboratories in which the Smalltalk language was born, the objects communicate between themselves by interchanging __messages__.
May be these interchanged messages based on XML?, May these messages be streamed, optionally, at least ?.
My response is: it would be better that way. it whould be a better way to communicate computers processes. It whould be a better object oriented framework.
The next point is to define the objects themselves as XML descriptions , or, to be short, as XML documents. Why? Because XML has better tools for standardization and checking the conformance with the definition, XML has better extensibility too.
That´s part of what I call distributed document computing.
I hope to contribute with that to make think on what for me is the true problem: the wrong idea to extend a _particular_ vision of object orientation to network communications programming.
Such vision is based, and promoted, by the OO implementation of the mainstream languages, such is C++, Java etc, which assimilates message interchage to function calls whcich are implemented in the context of a single machine, with a shared, fast memory stack which store the call parameters.
In the network, there is no shared memory stacks, so, we need a paradigm shift (whatever this means).
I´m looking at lisp and prolog based languages, which promotes a different taste of object programming. (and, of course, to XSLT)
Sorry If I have been too categoric.
I want to hear about some of this stuff, just to check if my arguments are´nt crazy enough to make sense for you.
Generally my silence has been that I silently agree with your assertions. Take a look at http://c2.com/cgi/wiki?WebServices
.. this was something I wrote up a month ago and talks along similar lines about a "semantic data stream" where one can add parameters, etc. without having to worry about recompiling interfaces. Feel free to add to it / edit it with you own ideas.
Thinking about XML in terms of LISP is also something that's been on my mind. So, no, the ideas aren't crazy, but I don't think the mainstream thinks about LISP very much.
Thank you Stu,
I will look detaily the site you mention. I cellebrate your agreement about these opinions and I will very pleased to discuss these topics with you.
By the way, I have been checking the SOAP protocol, to make sure about the shorcomings I mentioned in the previous messages. And I have to mention some potential advantages of this protocol over other RPC mechanisms, used in CORBA and COM:
What difference SOAP messages from other RPC mechanisms is that the XML SOAP message is self-describing, in the sense that it contains, for each interchanged parameter, the parameter name, the type and te value. whereas other RPC protocols transport the values only, so , in the latter case, the correct interpretation of these values depends on a indentical interface definition between the two parts. that implies syncronized re-programming, not achievable at the Internet scale.
Due to the self description of the SOAPpackets, SOAP whould permit ,teoretically, for the receiver middleware to ignore parameters added by a new interface version, so old and new versions can cohexist between sender and receiver. Even Streaming can be possible, if SOAP is extended (there are no room for it today)
As far as i tested, none of the current implementations of SOAP makes use of the self description features of the SOAP data packets, so exact versioning has to be maintained between senders and receiver.
That limitation of current SOAP implementations are not satisfactory for web services , in which there whould be N x N interactions acrooss the planet, with N could reach hundred of thoundsands.
but, if, as I´m sure XML-ization would advance in the future, does it make sense to transmit a XML document by packing it in the form of a SOAP packet , just to re-create the original document in the other side?
does it make sense to create function interfaces with hundreds of paramenters to mimic what one only XML document can easily transmit?
And what about to define a complete SOAP API for each web service? is´nt better to define the equivalent XML documents to interchange themselves?
"does it make sense to create function interfaces with hundreds of paramenters to mimic what one only XML document can easily transmit?
And what about to define a complete SOAP API for each web service? is´nt better to define the equivalent XML documents to interchange themselves?"
Big agreement. We have a fundamental disconnect in our current languages and what soap provides us. We need mappings that don't require hundred-parameter functions, or object mappings that require 200 get/set methods. A "property container" approach is more appropriate, similar to using a HashMap to store the instance variables... you lose strong typing, but you gain productivity.
I think SOAP/XML as a wire representation is the major catalyst to push languages into the more dynamic realm of static analysis. By this I mean we will rely more on meta-data like XML schemas to validate code correctness in our compilers, similar to how EJBs & deployment descriptors are validated by vendor tools today... Because we just can't pay the productivity penalty of having to write out all of these function declarations and/or object property declarations over & over again. Code generation is not the answer, as it merely complicates maintainability... though with Java it will be inevitable in the short term.
Anyhoo, sorry for the delayed response, don't check back here often enough :)
>>As far as i tested, none of the current implementations of SOAP makes use of the self description features of the SOAP data packets, so exact versioning has to be maintained between senders and receiver<Well, not surprising. As I said earlier, this would require an app which is totally open-ended in terms of message parameter processing. That's a bit much to ask, isnt'it ?
But "strict versioning" is actually not necessary, as long as you ADD new things and never CHANGE or DELETE existing ones.
Hope I got what u're trying to say, but what u've just described sounds awfully like WSDL and UDDI are doing, allowing dynamic discovery of web services.
Doing XML/SOAP with EJB now is still at a very preliminary stage. I develop web services using the standard Apache SOAP and you can't use EJBs without some sleight-of-hand. It's a very compelling reason though.
There is a new product that just went GA called CapeConnect. Development appears be done in Dublin, Ireland (I got a call from Dublin after downloading the beta). While I haven't gone through the full cycle of reviewing it this looks like an early solution to fully integrating SOAP and J2EE.
I don't know about streaming, because I have never had any such requirements, but in the case of parameters, yes, of course, that is the big advantage: add some new ones, and an "old" app will not notice, whereas the "new" app which needs the new params will be delighted...
It is even the idea with Web services: you first send a SOAP message asking the service for its parameters, and you then send a correspponding answer. But somebody will have to come up with "learning apps" that can dynamically adjust to such potentially changing service invocation ! As usual, easier said than done. Anyway, the basic idea is there, and can effectively be used.
But it's not a new idea. EDI's basic strength is exactly the same: add sone mew stuff, and all the recipients will still be able to handle your messages without coughing, but they CAN take advantage of the new stuff by modifying - at their leisure - the parsing on their side.
PS: sorry for late answer, I just started to look at the site really today...
SOAP/XML/EBXML/XMLRPC and EJBs can coexist for this very simple reason. SOAP(et al.) is a messaging protocol. EJB is an application architecture. Think of SOAP as HTTP, TCP, EDI or what have you and think of your EJB Server as a web server.
In regards to the comment about Java/EJB giving a performance hit, I have a few points to make. When Java first came out, the high-end desktop was a Pentium 100 with 16 Megs of RAM. Today's high-end desktop is more powerful than the high-end server of five years ago. Consider this, in 1995, my high-end computer would take about an hour to create an image using POV-Ray. My 866 AMD Athlon can create a five minute animated scene in the same time today. Five years ago, I would have agreed with you about Java's performance hit on the server side. Today the performance hit is negligible. As a matter of fact, the bottleneck for a web application today is the webserver (of all things).
So to sum it up, no SOAP/XML will not replace EJBs/J2EE, they are actually quite complementary together. And no, Java does not create a noticeable performance loss as opposed to a native application. (Consider that today's high-end server is a Dual Pentium 4 1.5ghz with 2+gb of ram and [name your amount] of storage.)
J2EE and SOAP will be the vanguard in providing B2B digital communication.
SOAP is not a replacement for any component standards, but will facilitate integration between different systems. The platform and programming languages used in each system will not be important in this respect.
This means that each party participating in an integration or web-service implementation can use the best suited architecure inside their environment.
SOAP will also provide a way of passing messages through a firewall, with all the benefits and security issues this implies. It is great for integration, but bad for security. RMI/IIOP/COM communication is not allowed through most firewalls today. SOAP will therefore enable implementation of many applications/interactions not possible today.
There are also some alternatives to SOAP, but these are not implemented or in a state that, so that the can be used i production applications:
TietoEnator Consulting AS
I had a dream about SOAP servers becoming more and more popular and XML evolving from a self-contained data trasnport "protocol" to a language able to contain data as well as behaviors. XML msgs evolved to agents. Microsoft had also integrated SOAP servers in everyday's desktop computers. EJB server were nicely integrated with all this.
is XML being used for what it was really ment to be used?
General reply to add to all comments.
I know that EJB Container is an implementation of all the middle tier services for the runtime environment of distributed object, very much like IIOP with Corba services prebuilt and implemented. I am not trying to compare EJB to a protocol, in fact what I am trying to highglight is that almost every mechanism begins with a protocol, then it grows into what they call them these days, Application Servers. Just look at how this XML beast is growing in Persisteance, Presentation, and Marshalling, it has some serious coverage of technolgy domains.
Just picture this that in 1yrs time MATURE AppServers will appear that are SAOPnXML complient, what will happen to enterprise development then? why do I have to carry EJB and SOAPnXML? I think alot of NEW developments will look at SOAP/XML as a solution, especially if the XML performance improves, then you will be measuring EJB vs SOAP/XML performance, and I think it wont be long before you see SOAP/XML peformance approach that of EJBish based architectures. I mean we all know EJB is sluggish on peformance, any true middleware engineer knows that. Having an alternative to EJB, is in a way reducing EJBs market share. That is my point.
Cheers! and more later.
"Any true middleware engineer knows that EJB is slow on performance."
Depends on the application server. Most EJB implementations have traditionally been poor, though lately they've been better. The spec certainly has problems in some areas, but generally this is a reflection of the difficulty in designing a scalable distributed object system.
In short: EJB's are only slow if you don't know how to design a system to be fast.
Furthermore, I really would like to see what you think will replace EJB. I personally enjoy competition and would like to see an alternative. The problem, however is the following:
- Replacements aren't standards. EJB and the J2EE is a standard across vendors. EJB goes beyond "communication protocols" -- it goes into how one trains & hires developers, what design patterns are used, etc.
The biggest benefit of EJB isn't that you can interoperate with CORBA -- it's that IT shops don't have to suffer vendor lock in or deal with a dearth of skilled developers on a particular app server. The market becomes less fragmented this way.
- XML/SOAP/UDDI/WSDL are all great protocols to make things interoperable, but it remains to be seen if there will be a new breed of application server standards behind this. On the face of it, it makes little sense -- we already have two: .NET and EJB.
So, in short, if XML/SOAP app servers will make EJB obsolete, it will mean that either
A) the industry en masse embraces .NET and ditches their UNIX and mainframes for Windows 2000 PC's
B) .NET is ported to UNIX by late 2002 and corporations adopt it by mid 2003.
C) The industry en masse adopts proprietary application servers, eschewing the benefits of a standardized API / skill set.
A & B are unlikely. C is likely only if some *very innovative* and highly marketed application servers come out within the next 2 years, that support the integration XML/SOAP. I'd love this. But as a realist, I'm pretty skeptical this will happen.. and inertia may kill any innovation anyway.
The XML will not roll over EJB and EJB is not and will not roll over IIOP. EJB will be based on the IIOP (default setting of EJB 2.0 spec). XML will be used for inter-enterprise applications or web services while EJB will be used for internal enterprise applications or intranet services. This is due to the fact of the different ways to manage the security, performance and interoperability.
Reading all this great discussion you guys have going,one thing comes to my mind.XML started as a platform independent data format and Java being the plat' independent prog'ing language with EJBs( the sophisticated transactional,scalable and what other adjectives have you) there was a sort of completeness.
But XML has already made rapid strides into all the tiers of a typical application.XML/XSL/XML-FO on presentation,XML/RPC/SOAP on middle tier and XML/RDF/XMI and databases which store and serve XML directly ond XML supported databases.
But given the state of today's net environment and diverse software and hardware,it is more challenging to integrate, connect and enhance and performance tune applications then to build applications from scratch alone. There are whole set of different issues of connectivity,performance,distributed transactions,security etc. It becomes all the more important to loosely couple applications when they talk to each other so that a tremor( change) on one is not felt by another. I think XML-SOAP or RPC can do a great job at that. EJBs I think can still benefit by using XML serialization/marshalling as an alternative.That way they can still remain compatible with IIOP talkers and newer XML apps.
XML, I don't think presents a threat to EJBs existence in near future unless every one decides to go top gear on XML and use it blindly everywhere (including modelling business rules in XML,persisting business data in XML,making XML messages transactional,modelling enterprise security in XML etc) and phase out EJBs and that is very unlikely.
I beg you pardon for talking at a different level but I think it is necessary to start from fundamental concepts:
XML and the XML DOM, As well as the XSLT ara about list and tree habdling, the best know example of a previous technology is the LISP language, which handles s-expressions. I wanted to see the Web as a repository of structured knowledge in the form of s-expression to be managed by lisp like languages.
Now this is being done by XML and the XML handling languages.In fact this description is according with the Semantic Web initiative, from the Web creator, Tim Barners Lee.
XML permits message passing, which permits streamed processing (which is indeed importand for scalability). XML also have class publication(trough DTDs and XML schema), which ideed facilitates standardization. It is also easily extensible by its own nature, without affecting the XML handling logic. A XML document can be verified against his DTD or XML schema, so the standardization is less prone to human interpretations.
SOAP, on the other side, is function call oriented, and as such, is API oriented , as is any Object oriented framework, like EJB. The standardization of a growing quantity of API´s is a serious concern, since there are no standar to describe API´s, no automatic verification of object definition against the standard and so on. the standardization problem grows when the boundary to be stadardized is stateful.
Function call oriented interfaces have no streaming capabilities, since the called function starts upon the complete list of parameters arrive. -Unless one of the paramenters points to a stream (hopefully,a XML stream), which reverts inded to a message passing interpretation of the stream-.
My bet is that the inherent superior flexibility, expresivity and ubiquity, accesibility and standardization of XML will lead to more and more processing to be done in the streamed document side, rather than into the function calling side, with less API´s and more document definitions. (a la MS Biztalk server)
Of course, even, transaction management, load balancing services and so on are needed.
So object frameworks, plumbing services and even OS´s and computers will survive.
(sorry for my bad english)
I see XML processing usage to gain growing extension from presentation and inter service communication to storage, inter process , and finally, to the core of the bussines processes, the middle tier.
WHERE is the spec for XAML?
About programming languages as such... Once and forever, a context-free programming language should become a basis for all of our development efforts.
By context-free I mean an absolutely formal language, so that semantic meaning of any expression written in it can not be interpreted depending on context, in other words, it any expression is unequivocal and has one and only one menaing. These languages are formal, can be automatically checked for semantical (not syntactical) correctness.
Java is not one of these, even though I love it for reasons too numerous to provide here.
I mean, that's the future, guys and gals. Context free languages, and XML is on it's way there. It's not programming language, but XML's self-descriptivness, schema, validation, etc. can help in development of a context free programming language of the future.
We need to automate prooving of correctness of our systems.
Let's be serious, what did IT as profession achived in 40 years? Bugs, bugs, bugs. Here is a new idea: no bugs by design. Semantics, people, semantics. The whole IT industry is build on the foundation of buggy software, businessmen love it, since fixing bugs is a big business.
I can imagine a corporation, which mission statement is:
We are in bugs fixing business. We make them, we fix them.
There are formal context free OO languages - Z, or something like that.
I think, what we are doing right now in SW and App developemnt is just fooling around and pretending how smart and knowledgeable we are. But the truth is, we just are not serious about 100% correct systems.
Let us say I am writting a program to add two numbers. Instead I write in my code, something that multiplies the numbers. How is context-free language going to help in fixing/preventing this bug ?
coming back to SAP versus EJB, it seems that while currently both SOAP and EJB seem to belong to different categories and can co-exist, I dont think it to be unlikely that as the SOAP phemomena catches on and the specification evolves, it would slowly and increasingly take on more and more of the functionality of the EJB specs such as providing a container for transactions, security, etc. I just hope that SUN takes a lead here and incorporates SOAP within the J2EE specs and prevents this from happening
I agree Viktor.
And the most common bug on distributed applications are related with interface mismatch between pieces of distributed code.
And the error is not only related to the data to interchange expected by both sides (in this case a good XML validation at RUN time trough DTD´s or schemas stored on a common server can solve the problem). The mismatch often appears in the API itself, that is, one side has a a new function call that the other side don´t.
In this case, a formal API definition (a IDL)trough a common XML, like in the former case, may NOT solve the problem since there are NO way to verify that a particular API implementation adheres completely to a particular IDL (not to mention to verify if the piece does what it must do), and, furthermore, there are no way to check the API interface conformance against the -centrally stored- formal definition at RUN-time.
In the other side, a set of messages written in XML and their associated formal definitions: DTD´s and/or schemas can describe most of the logic implied on current distributed problems. Furthermore, their formal definitions and processing tools (DOM, XSLT, Xpath) have enough flexibility to accomodate DIFFERENT versions running in the same envirionment.
Thinking conceptually a bit, as Viktor said, XML complex messages may be considered as true interpreted declarative programs which are interpreted by the respective (producer and consumer programs) on both sides. these programs doens´nt matter as long as it does what it has to do, at each side responsibility. That is because the CONTRACT between both sides is no longer a paticular API but the set of XML documents interchanged.
It seems to be a lacking piece in this schema, and it the workflow, the states, what message follows another mensage and so on. This may be defined by one more XML document. Microsoft (Xlang), IBM and HP, I checked, have XML languages for this purpose. (but most often this kind of descriptions are'nt to be used but for documentation purposes, except when you want to work on a higuer level of abstraction (using BizTalk, for example))(love lisp).
Of course, still each piece of code can have bugs, but we know how to deal with a single piece of code under our total control. (If not, split it in pieces and XML-ize it!).
Owever there are no way to automatically detect 2*2 instead of 2+2 in the code :(
I met some newish software consultants and they are learning SOAP. Guess that sums up what will be used in the future. heck, look at HTTP. Really weak and sloow but the #1 data transfer protocol. (OK, you can argue for NFS, SMTP, etc.)
SOAP, like HTTP is super-simple. Sure, you would have to change your transaction co-ordinator etc. to create a robust system.
The real winner for SOAP is the dream of EDI. How can companies ever integrate software? How can EJB's from multiple companies ever communicate? Duhh! Let's use XML. Let's use SOAP. That's the answer. Well, once you define the schema (data tables, relations) and possible values (I guess this is considered schema too), then you can really exchange data. The medical and insurance industry are supposed to do this someday a la HIPPA passed in to Federal law. Most think this days will slide out for years. It doesn't make business sense to pay insurance claims fully and on time and there are a lot of middle men here who would not have jobs. Hmmm. No you really need to think about what defining everything for your industry means. You can do it in a public way - an open definition. Then a web server/App server/Middle ware vendor can release their SOAP/XML system. They can fully support the open definition. Unfortunately, you might really be a middle man yourself. Well, that's the dream of SOAP - all data, accessible everywhere. Sort of the parallel of ubiquitous computing and infinite internet everywhere.
RMI is pretty cool because it remove some IDL definition steps etc. Java fully supports persistence - this was a claim for COM way back in 1996. Guess it does it now. I did a site which used XML fully internally. Tons of overhead in converting from SQL to XML and back constantly. That was 1.5 years back so maybe technology is better now. As to technology, the Java stuff and the COM stuff is almost a perfect parallel from the computer science viewpoint. Web pages for user views, logic in some code (scripts, objects), may want to call some remote objects (woohoo), read and write a database. Support for transactions and shared memory (session and context variables). The nice thing about programming in Java is that it works fine on whatever. The bad thing about XML is that everybody thinks it is a solution rather than another way to encapsulate data. As if RDBMS's just suck or something. Whenever you pass sufficiently large amounts of data between computers, a good definition of the data is useful. Not sure that XML will be better than blobs. XML seems alot like Union'ed data. You might have a block of data but it might not really be the <i>right</i> data. My $.02.
i agree with this
I think that EJB is is first of all a component based technology while sa SOAP is a communication protocol ,to bridge the barriers among defirent sysytems,so both will be there and non will be holding other back
I see two recurring positions in this thread. Namely:
1. SOAP/XML/etc. is a "wire-protocol". EJB is a server-side "component-architecture". They do not compete. Comparing them is like comparing apples to cars.
2. If one simply designs to the EJB "component-architecture". The "wire-protocol" then becomes a mere implementation detail - to be implemented by the app server vendor - transparent to the developer.
While there is some truth to this, it misses an important point: That is, the two things, component-architecture and wire-protocol, are tightly interrelated. As an example, before EJB, we had (and still have) a lighter weight component architecture called RMI. RMI used as it's wire protocol JRMP. The two went together. If you said RMI, JRMP was assumed and visa-versa. Then one day Sun decided that they wanted RMI objects (or components) to support multiple wire-protocols: JRMP and IIOP. There was a problem though. The RMI "component-architecture" was incompatible with the IIOP "wire-protocol". To name a few examples:
1. RMI supports passing serialized objects (per sun's serialization spec)
IIOP did not support this.
2. IIOP formally supports the notion of "security context" and "transaction context" as implicit parameters. RMI doesn't.
3. RMI supports distributed garbage collection. IIOP doesn't.
So what happened? They (Sun/OMG) defined a new protocol called RMI-IIOP. This stripped some features and added some features. What's more when using RMI-IIOP, you must be careful not to rely on certain RMI features (like distributed garbage collection) that are not supported in RMI-IIOP. IOW, the component-architecture (RMI in this example) had to bend to meet the wire-protocol (IIOP). And the wire-protocol had to bend to meet the component-architecture.
In the EJB (and RMI) world, a commonly recommended design pattern is to use a "few" course-grained method calls as opposed to a million fine-grained method calls. In Java land this usually means "serialized objects". Below is a typical interface using the EJB "component-architecture" (it's from Richard Monson-Haefel's on-line tutorial):
public void reserveRoom(Customer cust, RoomInfo ri,Date from, Date to)
public RoomInfo availableRooms(Location loc, Date from, Date to)
This interface (which is not atypical) has a dependency on java's serialization format. RMI-IIOP could be used. JRMP could be used. SOAP, in all practicality, CAN NOT be used.
Also, despite the fact that the 3rd "I" in RMI-IIOP stands for interoperability, it's not very interoperable. Please correct me if I'm wrong. If there are any VB, Powerbuilder, Delphi or MS VC++ developers in this thread who have remotely invoked EJB methods (like those above) please chime in.
In summary, you can not consider a server-side component-architecture without also considering the wire-protocol. The two are inseparable. Also, if I had to standardize on one and let the other follow, as an "implementation detail". I would choose the wire protocol. And it would be XML based.
I have to disagree on your in regards to a few of your thoughts on interoperability and RMI-IIOP.
Yes I have had PB and VC++ talk to EJB's which use coarse grained value objects as parameters to method calls as you list out. Your concern here is that to pass such a coarse grained value object requires that you use RMI styled serialization. This is indeed incorrect. According to RMI/IIOP semantics, the following types are passed via IIOP/GIOP serialization: primitives, IDL types. All other object types are passed by RMI serialization. The difference is that you can easily design your value object types to also be legal IDL types such as a struct, enum, etc. This would then allow them to be marshalled via GIOP serialization, which would then in turn allow PB, VC++, VB etc to call to, and pass/read parameters to/from an EJB. If you are at J1, please come see my presentation on thursday night. Id be glad to talk about it more, after you see my presentation.
Also remember as of J2EE 1.3 (read EJB 2.0) application server interoperability via RMI/IIOP is absolutely required, which means IIOP interop across vendors will be a more serious reality.
Dave(Wolf) what you say if in future soap would be the protocol to aceess EJB instead of RMI/IIOP? Just want your thoughts? BTW I am not a SOAP fan, but it seems to me that is the new trend in the market and we gotta use it; and you know why? becuase it is new and we are such a smart developers!!!
EJB has not edged out IIOP. If anything EJBH1.1 is dependent on IIOP. Corba offers ejbs the oportunity of being viewed a business objects regardless of their language specificiation. In much the same way you can have c++ or cobol objects, all of which corba supports. At the end of the day corba provides the ability to support business objects regardless of their language specification through the use of IDLs. All that matters is the API of the object in question when it comes to usage.