Let me explain a little bit more remember the detail is in the paper …
Service Oriented Architecture is all the rage. All the pundits and many businesses agree that business applications built using an SOA approach will help a business deploy business processes that make it more competitive but this only works if you have a really good platform on which to build those composite apps.
Roll out SAP NetWeaver!
Using SAP NetWeaver to build composite applications out of Web services is a very good way to go if only because SAP is re-engineering all its existing solutions using it SAP is making sure it works well in every respect.
But you can’t build a composite app unless you have your services built, so where do you get them from? You could build all your services from scratch but it doesn’t make much sense as much of the functionality you will need for your composite app probably already exists in your SAP, and non-SAP, systems.
Roll out Enterprise Services Architecture!
The Enterprise Services being built as part of ESA are exposing functionality in existing mySAP and other SAP solutions as web services. This means, especially if you have an SAP system, that you won’t have to build those services yourself. This will save you a lot of effort and if you use NetWeaver as part of an SAP implementation you will get all these services pre-defined.
But SAP solutions can’t work in isolation as more and more businesses outsource some of their activities or exchange business documents with their partners. This often requires connecting SAP and non-SAP systems both inside and outside your business. This means you have to standardize on how you connect if you want to connect to other systems easily.
SAP takes standardization very seriously and works hard in standards groups to make sure that Web services and Java standards, to name but a few, work well for building business applications. SAP also tests that SAP NetWeaver interoperates at a technical level with solutions from other vendors as part of the Web Services Interoperability Organization.
But technology standards such the WS* stack that includes SOAP and WSDL dont completely solve the problem. If you dont know the semantics of a SOAP message, i.e. what each piece of data in the message means, your applications won’t work. For example a shipping date could be a planned, required or actual shipping date. You need to know which and you can’t rely on always guessing correctly!
So SAP also specifies semantic standards for business documents, such as orders and invoices, in standards groups such as CIDX, RosettaNet and others. We are also doing the same for ESA, by specifying the semantics of the messages sent and received by Enterprise Services very carefully.
So now you know why the paper is called Building Standards Based Business Applications it’s the way you’ll probably be building many of your business applications in the future.
But this is just a summary. If you want all 14 pages of detail of what SAP is doing in this area read the paper …
and if you have any questions, I’ll be pleased to answer them.