|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
J2EE patterns
J2EE patterns
J2EE patterns
|
Messages: 1
Messages: 1
Messages: 1
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Ripping off services layers, bad idea - about the ESB
Taken from: Thoughts on SOA and EDA
"Hey Jack, could you please rip off the services layers from all of our systems?"
This question comes to me occasionally. Not exactly in these words. It is more like "Why do we need XI, Sonic, Cordys and Biztalk while we already got our WebSphere ESB... Why having more than one ESB?"
It's right, we - at Dutch Railways - got a WebSphere ESB. But it's wrong to think we got more than one ESB when we also have SAP-XI (PI), Sonic ESB and Biztalk Server. Vendors all call their product an ESB, because they want us to use their product as an ESB. But in fact these products aren't ESB's - including WebSphere ESB - unless we give the product this enterprise role, what we did with IBM's managed services layer.
What vendors sell are managed services layers. We could e.g. access native SAP services from the core of the system. But fortunately SAP decided to put a managed services layer - PI - in front of its core system functions. This managed services layer provides a registry of services and it offers ways of governing the services. It also hides lower level system services and guarantees the integrity of higher level - composite - services.
Our .Net based application systems use Biztalk Server for the same reason we use PI for our SAP systems. And we got the APAMA event processor, which we think of to use Sonic to manage the system level services layered around the event processor. And last but not least there is the CORDYS BPM suite, that leverages the CORDYS services layer which is called the CORDYS ESB, just like Progress calls Sonic an ESB and Microsoft - sometimes - calls Biztalk Server an ESB. And that is confusing and obscures straight forward thinking.
An ESB is not for sale. Sorry Sonic, despite you invented the acronym (or was it Gartner), it is not the vendor who decides which services layer product gets the role of Enterprise level - cross domain - services layer, the ESB. It's the enterprise itself who decides.
Back to the beginning of this post: "Bad idea, dear people. I am not going to rip off the managed services layers from our systems. The system level services layers are the ramps to our enterprise level services layer. It releaves us of the burden to dive into the muddy pools of obscure native web services in the core of our systems while a robust and structured access layer is available. Think in more then one level."
"Huh..? And what about all those separate services management environments?"
"Don't worry. Registry federation tools and standards exist. And SOA (function) and web services (technology) federation tools are emerging. You may want to Google around a bit..."
-Jack the Architect
|
|
|
Message #310845
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Runtime SOA management tooling
Please have a look at Amberpoint. A cross platform SOA runtime management tool to keep in control of these heterogeneous service layer environments....
|
|
|
| EJB Design Patterns PDFEJB Design Patterns PDFEJB Design Patterns PDF |
|
|
EJB Design Patterns is now available for free download in PDF format. The book contains a catalog of twenty advanced EJB patterns and provides strategies for mapping application requirements to patterns-driven design, J2EE development best practices, and more. EJB Design Patterns was the #2 book at Java One 2002, and held the #1 Java book position on Amazon.com for weeks since the book was released in March. Download your PDF here.
|
| Useful patterns around the webUseful patterns around the webUseful patterns around the web |
|
|
This
essential pattern describes how to model your entity beans.
How to make an entity bean a facade to a set of dependent objects.
Every guru should use unit testing.
|
| Other Patterns sitesOther Patterns sitesOther Patterns sites |
|
|
|
The original reference
site for patterns. Frequented by the gang of 4 and their mentors (Kent Beck, Ward Cunningham).
A catalogue of J2EE design patterns from Suns Consulting Division.
A catalogue of
high level business, architectural and topological patterns for large scale systems.
Design Patterns from the J2EE Blueprints, Suns authoritative guide to J2EE development.
|
|
