Does IS provide location transparency

, , ,
1

Some time back there was a discussion around the virtues and limitations of the 6.0 architecture. One of the details addressed the concept of “location transparency” which refers to the ability of an application participating in a messaging network to be blissfully unaware of where other participating applications are located.

There was some brief debate about whether or not IS, with or without TN, provides location transparency. What’s your view? Does it do so or not? Prepare to defend your position! :wink:

2

I will ask doesn’t the answer depend on situation; and also on the design one has implemented.

If webMethods is used as a pass thru (point to point integration), (this happens more often than we think), I guess, “location transparency” is lost.

Else, in highly integrated enterprise (?), I guess to some extent IS provide location transparency.

Lastly, referring to the other thread on this, I will say that old Broker 5.x and new IS 6.x will have the SAME answer to your question depending on the scenario/implementation.

3

Interesting that you equate ES 5 and IS 6 (at least for this topic). Can you expand on that a bit?

4

In addition to “location transparency” we might also throw into the discussion “application anonymity” – not only doesn’t a publishing application know where another application is located, it doesn’t know WHAT the other application(s) is (are).

Consider for a moment your own integrations–what would you need to change if another application started consuming your documents? Nothing? Everything?

5

Hi Rob,
My experience with webMethods had not been for complex projects (like to integrate 25 or so applications?)

As we very well know, there is difference between theoretical and practical approaches; and so is the difference between sales pitch and real world implementation.

The integrations I have come across, makes me say that “application anonymity” and “local transparency” are concepts one should aim for.

Does that mean this can’t be achieved in real world scenarios. No, I am sure it does, but I haven’t come across it.

For me, integrations start with looking at integrating applications and building a solution for that need. Which in essence means that if one more applications need to use the data in same format in future, well and good. But what if, the new application needs additional data from the source. Wouldn’t that require a change and have “application anonymity” concept evaporate. A requirement from that application to have just one extra field/value from source, and that’s it.

I know in ideal world that shouldn’t happen; but yes, we live in times where “new” application wouldn’t relent on making any changes on their side (they have more say in project; or they are just too lazy to change), hence a decision is reached and the changes are made on source side. I have been in such situation more than once, and am sure you would have also faced it.

I guess, I didn’t sound too discouraged on the way I see the difference between the way integrations should be handled versus actually implemented.

As far as equating ES 5 and IS 6 is concerned, I (in my limited experience with 6) feel it is flexible enough to let one design solution for a requirement same way. But that doesn’t mean that resulting architecture will be the same in terms of how many IS instances, Brokers, adapters are installed.

And all the above, IMHO and limited experience.

Please share your thoughts and I am sure I will (as always) have more to learn from your posts.

  • Saurabh.
6

Rob,

Great discussion.

Can you provide an example of “location transparency” in practice?

Is your assertion that this was possible prior to IS 6.x or with a 100% broker solution, but not with IS 6.x? If so, how did you achieve location transparency?

How would you achieve it with JMS, MQ Series or other “messaging network” providers?

Mark

7

I’m a bit confused after reading the original post several times. If the application is calling the local broker or IS at it’s location and simply publishing a message then how would the application have to be aware of the other applications and brokers on the network? The broker is aware but not the application. If you took it a step further and used as common document or message and JMS as the protocol then app’s interaction with the WM broker becomes generic except for some small details about the service provider that is required for all JMS providers implementations. The broker is still aware of the network but the application is not nor does it need to be.

WM could then be replaced if needed with any other JMS provider with the application still unaware of any of the underlying infrastructure. It is possible I misunderstood the original question, my apologies if I’m going down the wrong track here.

8

Looking forward a release or two, what will it mean when IS web services can be published into an ESOA “fabric”?

Wouldn’t this give your web services location transparency as well as your message-oriented integrations?

-mdc

9

Saurabh: Completeness of the message/event/document will almost always be an issue. One can try to address this via canonical document approaches, and being business-process driven (as opposed to application driven) but something invariably pops up. The main application-independence item to address, IMO, is content–which codes are being used? Are they from a specific app or are they defined by the business and used by the app?

Mark C: I was hoping to get independent validation of my own POV on the topic and doing so in such a way as to not share my POV too early–attempting to avoid “leading the witness” so to speak. :wink: I’ll post my thoughts in a day or two.

Mark G: You’re definitely on the right track with the material you are providing. Please continue if you have more.

10

Interestingly, I’ve done a lot of work on a U.S. DoD project where one of the primary benefits typically touted is the “location transparency” of data with the system. This was achieved via an abstraction layer above the (theoretically heterogeneous) DBMS that (at least somewhat) answered the mail. In our design of the next generation of this system we considered the pub/sub messaging model as a potential replacement for our virtual DBMS.

This didn’t come to pass, due in part to our unfamiliarity with the paradigm and in part to the perceived complexity involved in setting up all the pub/sub relationships that would be required to implement all of our existing functionality.

However, there was certainly an interesting theoretical possibility there that we would have been willing to explore on a smaller scale. I do still believe the pub/sub model (not ES/IS in particular) holds promise for true data location transparency, and for that matter application anonymity.

Regarding Mark’s last post, I was beginning to devise just such a concept after debating the merits of migrating some internal services to Web Services for another recent project. The stumbling point seemed to be that Web Services offered us no more location transparency than a remote invoke, so I was wondering if these could be combined with pub/sub to form the ideal solution. Sure enough, I attended a wM webinar on Fabric and heard that this would indeed be possible in a coming release. Just can’t beat those product development guys to the punch very often. :slight_smile:

11

If I understand the terms correctly

I would say the answer is yes.

The wm platform does provide the means to achieve the anonymity - both of location and application.

TN documents (along with processing rules etc) could be used to push documents to, or pull documents from the target applications - as business rules required - independently of where or from what application the document originated.

So applications only interact with TN - not with each other.

Haithem

12

Starting with the concept of a pub/sub messaging channel that can receive documents from publishing applications and publish them to the subscribing applications and wherein the routing and data transformation is the channel’s responsibility [and hence encapsulated within the channel implementation logic]. The publishing and subscribing applications here, would be channel aware and would know nothing about who or what is publishing/subscribing to the documents.
A publishing application talks to the channel to publish the documents and similarly a subscribing application would get only relevant documents[for which it has a subscription with the channel].
Now if we equate the IS, with or without TN[or for that matter any other middleware],with a messaging channel then I think we can say that IS supports both “location transparency” & “application anonymity” for the publishing & subscribing applications.
The routing information in IS could be with the broker, with TN[for B2B] or with some other custom code sitting on IS. But, In effect this information is with IS and the addition/deletion of another consumer could be easily managed at the IS level, without the publishing application being aware/impacted due to this change…
what do you say?

13

Assuming by “location transparency” you mean something akin to “services and clients operate independently of their location” then I think you can achieve this with IS using careful design.

Since most web services implementations (including IS) are point-to-point by nature, introducing some of the service registration / service location features of an SOA would be necessary to achieve location transparency.

For “application anonymity” you would need to add careful canonical design or, if using web services, careful schema and WSDL design. In addition you would need services to convert between an applications native representation of business objects and the organizations (or industry’s) canonical representation.

IMHO, IS not only doesn’t inhibit location transparency, it provides many of the key ingredients to make it possible in a way that is extremely difficult to achieve in solutions involving only message brokers (or JMS providers).

Mark

14

Mark C.'s statement about the definition of location transparency brings up a good point (in that we need to define it :-)). What I was referring to was location transparency of the data within a system, i.e. - an end user of the system doesn’t need to know anything about which database/application/system is storing the data they need, or where that data physically resides. By establishing an appropriately structured taxonomy of events/messages in a pub/sub system it may be possible to affect just such a goal.

Location transparency of services seems to be another goal. Of course, the physical location of a service is transparent using wM, as the DNS is responsible for discerning that piece of information from a URL, which is all a client needs to know in order to invoke the service. I suppose it’s also plausible to contend that pub/sub messaging obviates the need to know the URL as well, provided the client can publish an appropriate document to the Broker.

For Web Services, I agree that registration/discovery services can facilitate identification of a service’s location, but they don’t eliminate the need to know it. I’d be interested in hearing more about how IS (or Glue/Fabric, for that matter) facilitates this concept, though.

15

Here are some resources describing “transparency” in various forms.

Focus on distributed objects/components
[url=“http://www.cs.adelaide.edu.au/~katrina/falkner.pdf”]http://www.cs.adelaide.edu.au/~katrina/falkner.pdf[/url]
[url=“http://c2.com/cgi/wiki?LocationTransparency”]http://c2.com/cgi/wiki?LocationTransparency[/url]
[url=“Funducode Residential Pest Control & Commercial Pest Control Services”]Funducode Residential Pest Control & Commercial Pest Control Services

Focus on services
[url=“http://www.builderau.com.au/architect/sdi/0%2C39024602%2C20272631%2C00.htm”]http://www.builderau.com.au/architect/sdi/0,39024602,20272631,00.htm[/url]

Focus on data
[url=“http://www.cise.ufl.edu/help/database/oracle-docs/server.920/a96521/ds_admin.htm#14267”]http://www.cise.ufl.edu/help/database/oracle-docs/server.920/a96521/ds_admin.htm#14267[/url]

General
[url=“penguin:files:part1.ppt [OS3 Website]”]penguin:files:part1.ppt:url [OS3 Website]
[url=“http://homepages.tig.com.au/~ijoyner/Transparencies.html”]http://homepages.tig.com.au/~ijoyner/Transparencies.html[/url]

webMethods Advantage hits turn up references only to Fabric (Fabric focuses on services):
“webMethods Fabric provides a standards-based registry that organizations can use easily to catalog and publish web services across an enterprise. Consumers can dynamically discover and use these services without coding specific endpoint addresses to achieve true enterprise-wide location transparency.”

I always have to chuckle when claims about “true” <fill> are made.

16

Rob,
Good discussion. I really liked your last point about true location transparency. SOA which was invented by Gartner I believe , hopes to takes us to the nirvana of application development and deployment. But as we know, the details are what get you. Effective SOA requires highly disciplined development organizations and who also have a lot of influence with their clients. Of course I know we all work for such organizations.

markg

17

borrowing the definition of “Location Transparency” from
[url=“http://homepages.tig.com.au/~ijoyner/Transparencies.html”]http://homepages.tig.com.au/~ijoyner/Transparencies.html[/url]


2.3. Location Transparency
Location transparency masks the location of an object in space. As an example, WWW URLs are not location transparent, as they contain a host name where an object (Web page) resides. Location transparency depends on chosing a location independent naming scheme. Location transparency enables the named entities to be moved, without notifying all parties who carry a reference to the entity of the changed reference.

With above in mind, I will say webMethods does provide ways to achieve location transparency. and additionally “application anonymity”.

and rightly said before, attaining this goal of ODP (open distributed processing) depends on the choice of design and implementation.

18

Here is my take on “location transparency” as it pertains to IS. A couple of pre-requisites first.

Definition that I’m using:

lo·ca·tion trans·par·en·cy - the ability of an application participating in a communication network to be unaware of where other participating applications are located

Integration Server roles:

  • Services environment – Executes business process and services accessible via http, ftp, e-mail, SOAP, etc. Services usually rely on accessing other data, applications, services hosted elsewhere to fulfill their function.

  • Adapter run-time – Functions as an intermediary between some resource, such as a database, and the webMethods Broker. Translates data from the resource to Broker documents (aka events or messages) and vice versa. Services hosted by IS in this role are defined by the adapter author.

  • General-purpose broker – The services environment can be used to function as a broker, which is generically defined as any intermediary between two or more applications that need to communicate. One application passes data to the broker and the broker passes that data on to other applications as needed (transforming the data if required). True, IS doesn’t provide pub/sub to the extent Broker does, but even without pub/sub, IS is a broker. TN adds to its brokering capabilities (and not just with external partners).

As Mark G. stated in his first reply to this thread:
“If the application is calling the local broker or IS at it’s location and simply publishing a message then how would the application have to be aware of the other applications and brokers on the network?”

Exactly. It is my contention that IS provides location transparency (as defined above) directly out of the box with virtually no effort at all. Only when IS is used as an application in and of itself (e.g. you’ve written some services that stand on their own) does it not provide some level of location transparency.

Even when using IS for its web services capabilities, you get location transparency. Not for the services themselves, but for the supporting “behind the scenes” players that help make the service work. To get location transparency for the services themselves, IS needs help (Fabric fits the bill).

All abstraction devices that try to simplify the multiple, point-to-point web of connections (device drivers, naming services, brokers, directories, etc.) use an intermediary. By definition, that intermediary’s location must be known (or resolvable) to the client/application. A broker itself isn’t location transparent. Adapters, clients, services, etc. need to know where the broker is. But the broker provides location transparency for the applications that are on “the other side” of the connection.

Mark C. asked for ‘an example of “location transparency” in practice?’ Virtually every single IS-based project I’ve worked on provided location transparency. Some brief examples:

  • Orders in XML form sent from fulfillment system to IS via a queuing facility. IS translated the XML to EDI which were forwarded to external partners via FTP. The fulfillment system has no idea that the transformation is occurring, no idea about the communication methods and certainly no clue about which applications that the orders ultimately ended up in. Each of these components could change without the fulfillment system knowing.

  • Orders from a new J2EE system sent to IS via a queueing facility. IS translates and sends to a mainframe app via its EDI translator interface. The J2EE system does not know the orders are going to a mainframe. Indeed, it doesn’t know if the order goes anywhere at all.

There are others but I’ll cut