 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Tomcat - JSP/Servlet container | | Struts - A MVC web framework | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | JSP - A mailing list about Java Server Pages specification and reference | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | |
Struts & Hibernate
|
|
|
| | | Subject: Subsystems communication | Subject: Subsystems communication 2004-10-20 - By Chris Rowse
Back
Hi Andre
Aha .... finally we find the real case for middleware and JMS.
For complete decoupling of these services, together with publish /
subscribe etc.... run a messaging service to guarantee delivery (ACID).
I have seen many whinges about the 'heaviness' of J2EE, but each time I
design something, I see a really terrific reduction in complexity of
applications.
I just wish that JAXB would provide a switch to produce interfaces
only. I could then seamlessly integrate XML streams into and out of CMP
EJB.
At present I have an ant task that generates both JAXB marshaling
(through xjc) and EJB through XDoclet. I still have to generate a bit of
code to allow the value beans to be interchanged. I hate this.
If anyone has $$$ or time and promises to send improvements, I'll send
the code, or fix it properly (Hungry mouths to feed). I haven't had time
or patience to get the Struts / Webwork running (Hint $$$ in my PayPal)
but I then get the whole lot generated with a user interface.
Chris
On Wed, 2004-10-20 at 16:31, Andre Kovacs wrote:
> I'll use services too, but my point is centralized on subsystems
communication, not on subsystems and services.
>
> I found in the Gof Facade Pattern (p. 186) that dependent subsystems
communication should be done through it's respective Facades, reducing the
subsystems coupling.
> That's ok, but how it's done? The first subsystem Facade should connect
directly to the second subsystem Facade, or a first subsystem Service/Business
Object should connect to the second subsystem Facade? And since I'm already
into the business layer should the first subsystem connect to the second
subsystem using the second subsystem Delegate?
>
> Thanks,
> Andre
>
> -- -- Original Message -- --
> From: Chris Rowse <crowse@(protected)>
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: Re: Subsystems communication
> Date: Wed, 20 Oct 2004 15:19:58 +0200
>
> Re:
> Re: Hi,
> Re:
> Re: I am presently busy with scoping and sizing an application and am
> Re: finding that by going SOA using Web services, there is little or no
> Re: differnce between interfaces in these dimensions.
> Re:
> Re: It is purely the presentation and nature and authorisation of the
> Re: actor that differentiate the two dimensions.
> Re:
> Re: In my case, a banking environment, there are many interface
channels.
> Re: Substantial cost saving and reduction in complexity can be realised by
> Re: treating all interaces orthagonally (e.g. XML over HTTPS).
> Re: We are considering ISO / OASIS standards for all communications to
> Re: further standardise our interfaces ad make them more interoperable with
> Re: third parties.
> Re:
> Re: You also get better decoupling by separating the subsystems
across a
> Re: clear boundary. This may, and often needs to reflect the areas of
> Re: responsibility of the business units involved.
> Re:
> Re: Chris
> Re:
> Re: On Wed, 2004-10-20 at 15:03, Jin Chun wrote:
> Re: >
> Re: >
> Re: > Actually, I disagree somewhat,
> Re: >
> Re: > IMHO, one should always strive to layer the system 2
dimensionally.
> Re: > In one dimension, there are service interfaces that are use case/story
> Re: > modeled, and the other,
> Re: > are subsystem interfaces that may be reused across application domains,
> Re: > e.g. gateways, etc.
> Re: >
> Re: > Jin
> Re: >
> Re: > Jin Chun
> Re: >
> Re: >
> Re: > Vice President: Chief Applications Architect
> Re: > State Street ??? Global Link | www.statestreet.com | www.globallink.com
> Re: > 617.664.1695 | byungchun@(protected)
> Re: > SCJA SCJP OCP-DBA
> Re: >
> Re: >
> Re: > Confidentiality Notice: The information contained in the email is
intended
> Re: > for the confidential use of the above-named recipient(s). If the
reader of
> Re: > this message is not the intended recipient or person responsible for
> Re: > delivering it to the intended recipient, you are hereby notified that
you
> Re: > have received this communication in error, and that any review,
> Re: > dissemination, distribution, or copying of this communication is
strictly
> Re: > prohibited. If you have received this in error, please notify the
sender
> Re: > immediately and destroy this message.
> Re: >
> Re: >
> Re: > |-- ------+-- ---- ---- ---- ---- ---- ---- --->
> Re: > | | Ryan Wiles |
> Re: > | | <ryan.wiles@(protected)> |
> Re: > | | Sent by: An interest list|
> Re: > | | for Sun Java Center J2EE |
> Re: > | | Pattern Catalog |
> Re: > | | <J2EEPATTERNS-INTEREST@(protected)|
> Re: > | | VA.SUN.COM> |
> Re: > | | |
> Re: > | | |
> Re: > | | 10/19/2004 09:51 PM |
> Re: > | | Please respond to An |
> Re: > | | interest list for Sun |
> Re: > | | Java Center J2EE Pattern |
> Re: > | | Catalog |
> Re: > | | |
> Re: > |-- ------+-- ---- ---- ---- ---- ---- ---- --->
> Re: > >-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -----
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -----|
> Re: > |
|
> Re: > | To: J2EEPATTERNS-INTEREST@(protected)
|
> Re: > | cc:
|
> Re: > | Subject: Re: Subsystems communication
|
> Re: > >-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -----
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -----|
> Re: >
> Re: >
> Re: >
> Re: >
> Re: > Subsystems are a waste of time.
> Re: >
> Re: > Peace out.
> Re: >
> Re: >
> Re: > > I have a question regarding subsystems communication.
> Re: > > How do I integrate a subsystem with dependent subsystems (possibly
remote
> Re: > > ones)?
> Re: > > I found a suggestion saying to call the dependent subsystems Business
> Re: > > Delegates/Fa??ades from the top subsystem Business Object. Is this
> Re: > correct?
> Re: > > I don't feel comfortable with this solution because a think that if
you
> Re: > are
> Re: > > already in the business layer, why should I use a Pattern designed to
> Re: > > integrate presenteation-tier clients and system's business services.
> Re: > >
> Re: > > ===================================================================>
Re: > > Companion Site: http://www.corej2eepatterns.com
> Re: > > J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> Re: > > List Archive:
> Re: > http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Re: > > Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> Re: > listserv@(protected)
> Re: >
> Re: > ===================================================================> Re
: > Companion Site: http://www.corej2eepatterns.com
> Re: > J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> Re: > List Archive:
> Re: > http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Re: > Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> Re: > listserv@(protected)
> Re: >
> Re:
> Re: ===================================================================> Re:
Companion Site: http://www.corej2eepatterns.com
> Re: J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> Re: List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest
.html
> Re: Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
.com
> Re:
===================================================================Companion
Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
|
