cancel
Showing results for 
Search instead for 
Did you mean: 

XI in a ESA-scenario

Former Member
0 Kudos

Hello,

anyone can explain me when it is useful to use the XI in an ESA-Scenario?

Thanks for your help!

Accepted Solutions (0)

Answers (1)

Answers (1)

gregory_root
Advisor
Advisor
0 Kudos

Thomas,

Rather than reinvent the wheel, there are some great comments on this topic:

<b>Lothar Schubert</b> discusses how XI can help data quality in ESA (/people/sap.user72/blog/2003/12/14/esa-as-enabler-of-data-quality-assurance)

<b>Jason Wolf</b> in previous post mentions that XI supports strong de-coupling of the process from back-end systems. De-coupling is a key requirement for an ESA. ()

<b>David Sonnenschein</b> also discusses the benefits of extracting high-value functions out of existing systems and how XI provides higher level functions for Web Services like ()

Bottom line, XI is a key component to <u>ensure delivery of messages between enterprise systems</u> in an Enterprise Services Architecture.

Look forward to hearing from you.

Regards,

Greg

Former Member
0 Kudos

Hello Greg,

thank you for this helpful answer. I have an other question about this topic. Do you know a real ESA-project that is not using the XI as middleware?

A matter of particular interest is how can i handle for example monitoring and logging in a ESA-scenario without using the XI?

I'm a little confused because all SOA-examples that I've seen use a central infrastructure to enable the basic interaction between service components. So I don't know how a ESA-scenario without XI looks like.

Thanks for your help!

gregory_root
Advisor
Advisor
0 Kudos

Thomas,

I know of no project that is not using XI as the middleware. Why? Because no one wants to develop from scratch all the infrastructure services required to monitor and log communications between web services. This is exactly the benefit that XI brings: Each service exposed through XI will have consistency management, monitoring, transformation, composition services, Quality of Service management, auditing, etc.

SAP NetWeaver - Exchange Infrastructure and the included BPM engine (ccBPM) provide both the development tools and runtime services to do this easily.

Regards,

Greg

0 Kudos

Thomas,

XI and ccBPM provide many infrastructure or utility services that move a Service from being simple point-to-point solution to a managed Enterprise Service. They provide a substantial layer of abstraction and mediation for implementations that help accomplish the goals of ESA. As Greg mentions, real world examples of ESA will gravitate toward these solutions because the capabilities are required.

So, if you want to do Enterprise Services without XI and ccBPM you need to implement these capabilities yourself. For instance, if you need monitoring and the ability to re-play a SOAP message that never made it to a Service Provider, you must create a queue, create tools to interact with the queue, and expose the queue Service to Service consumer as a proxy for the Service Provider. You must do this to a Enterprise scale because you want to re-use the construct for all Services. I do not mean to imply that any of the above steps are hard, they are just needed.

You could create a Monitor Service and a Logging Service that you force all other services to call as part of every consumer request. In a sense you would have a business interface to the consumer, but you would force all providers to also make monitor and logging service calls as part of their implementation. Depending on how you go about this, you could end up with tight coupling between Monitor Service Version 1.0 and Business Service implementations you deliver around the same time. When you evolve Monitor Service 1.0 to 2.0, you will be faced with potentially updating any Business Service that used 1.0.

If you want to compose Services from existing Services then you need to make sure you have a mechanism to mediate change in the underlying services such that changes to a part of the composite service does not break the entire composite service. Failure to put this mediating layer in between will result in either fragile composite services or an increase in complexity for service consumers (they will need to implement some mediating code, which will also likely be fairly fragile given that it is re-implemented by each consumer).

Finally, with respect to the Netweaver infrastructure (XI, WebAS, ccBPM, Enterprise Services Investory and Repository) SAP continues to invest in exposing SAP core capabilities as Enterprise Services through Netweaver. To expose SAP core only through simple services leaves functionality we give you now, and we are enhancing in the future out of the Enterprise Services Landscape.

To your point about "Central infrastructure to enable interaction..." Long term I do think that a central, single infrastructure is not likely to be the answer for all services at all levels of granularity. I just suggest that you err on the side of robust, managed services because when you expose a service your really never know how consumers are going to use it.

In a real world scenario for a customer we expose two services from BW, an Authorization check for BW data as a Service and a BW Data Service that leveraged the Authorization Service, that we immediately used in an composite application in WebAS. In that example, the EJB-based application calls a simple Web Service exposed from BW. We did not go through XI, we did not add any other mediating or monitoring service. That was the proper approach for that particular need, and the level of abstraction and insulation we needed was provided by the simple service infrastructure of BW and WebAS. Now when other teams learned of the neat Data Service from BW we exposed and want to use it, should we just send them the WSDL and the endpoint address? I would argue that you should at least put some mediating infrastructure in between because neither party (Consumer or Provider) knows very much about the other. Adding this mediating layer has no impact on the original consumer-provider relationship that sparked the creation of the service, it simply protects future consumers. As consumers from all over the enteprise begin to consume our service we may need to change, bar, or even charge-back for the use of our service, so we need more control. We provide our Data Service as an enterprise service endpoint and then use all the NW stack to insure robust, auditable, secure, and changeable Services. Again, do you have to use XI to accomplish this, no you do not, but I would. We use both XI and ccBPM as part of the Service landscape for the customer I am referring to.

I hope this helps.