William Henry wrote:
> Our difference is that I am assuming that I won't throw away existing
> IT assets and rewrite them in Java and if we can leverage non-Java
> mission critical assets naturally why add the layer of Java? Whereas
> you seem to be making the assumption that rewriting them or wrapping
> them in Java is a most desirable.
I know that fighting the integration battle by continuing with a diverse
language set is painful. Wrapping legacy apps with web services interfaces is
no different than wrapping them with a Jini wrapper. The upside is that the
transport layer would be plugable and could be multi faced. Jini's Exporter
facilities would allow you to export a service with WS-* and native JERI
supported interfaces. This would give you the flexability to use the most
effective interface for your application. If you just do it with WS-*, then
everything has to speak WS. This forces you to standardize on a single
transport interface which can be a limitation in and of itself. The choices
available with JERIs plugable transport empower you to make the best choice of
transports that meets your needs.
> Having built your own proprietary brokers etc. is a luxury - (but
> proprietary ... unless you now have conformed to the specs).
My broker, because it uses a lightweight, native java ESB, can have any type of
external interface plugged in. I have JMS in/out, a private XML socket stream
inbound, and JDBC out plus several other vendor specific inputs. By not
driving
the core with a standard that has limits, I have the flexibility to plug in
whatever I need. That's an architectural advantage that just using WS doesn't
support.
> They turn to the elusive "best
> practices" for better guidelines. and just when they are about to
> "get it" a new Hello World demo from a new technology come on the
> scene to solve their problem and start the cycle again. But to assume
> that the Java specs are any less complicated than the CORBA or even
> the WS- specs ..... ?
Absolutely the Jini spec is less complicated! It's perhaps more technically
oriented (distributed systems problems are not simple to solve). This might
make you feel complication. I consider complication to be measured by lack of
flexibility and lack of features that make doing some things decidedly
difficult
if not impossible.
Having well defined behaviors with well defined programmatic interfaces makes
things a lot less complicated.
Learning something new can feel like complication. But, I think it's decidedly
shortsited to place training at the front of your decision tree.
> All I'm saying is this: Way to go Java! When you need to build
> something new and Java fits the need then use it. But let's not
> assume it will work in all cases and let's not force in in places where
> it's neither needed or wanted.
I would only argue that limiting your choices to "something new" is only
complicating your SOA. By having multiple languages/platforms visible to the
overall SOA, you are going to always demand using the most commonly available
transport/interchange/messaging system. Standards might be in place to make
this seem easy. But, if those standards complicate your design, or impact your
inter-system latency, performance and evolution choices, then they may not have
provided you with the "feature" that you needed.
There are infinite choices, making the right choice is important. Standards
aren't always the best choice, and often provide more value to the implementors
selling implementations than to the users.
I'm not saying the WS is not valuable. I'm only saying that it is a choice,
and
applying it to the backbone of an inhouse SOA doesn't make sense across the
board. WS can provide an inter-business backbone. But making it the only
choice will limit choices and increase your dependencies on 3rd party software
that you can't tune or adjust as needed.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
